Process · service requests
A service request. Missing details show up straight away, not two days later.
A service request is a piece of work, not a message to forward. The system collects the minimum context, flags missing details openly and hands the case to the team with a condition for moving on and one named task.
“Air con not working in the second-floor office. Urgent!”
Reported by: reception, 8 Example Street
- About
- Air conditioning, 2nd floor
- Known
- description as received · 09:14
- Missing
- unit serial number
- Condition
- photo of the rating plate
- Next
- engineer — schedule a visit
details missing instead of “to do”
Fictional data. Fields and rules are agreed for your process.
What comes in. What goes out.
01 · Comes in
Form, email, phone.
The description of the problem stays exactly as it arrived — with the date and time.
02 · The system sorts it
Context and open gaps.
Four questions instead of twenty fields. Missing details get their own status, not a note saying “to do”.
03 · Goes out
A handover with a condition.
Who it goes to, the condition for moving on and one task: “check the serial number”, not “deal with this”.
Four questions, not twenty fields.
We collect only what lets the work start. A full customer record isn’t needed to hand over a case.
- 01
What is it about?
The customer, the equipment or the location — specifically, without follow-up questions.
- 02
What do we already know?
The description of the problem exactly as it arrived, plus the date and time.
- 03
What is needed next?
Access, a photo, a serial number, permission to enter the site.
- 04
Who takes the next step?
A person and one named task, not “the team will look at it”.
An ordinary day in this process.
Every step stays in the log. Purple rows are where the system deliberately stopped and is waiting for a person.
- 09:14 Form: air con not working, 2nd floorcase #0533 done
- 09:14 No serial number for the unitstatus: details missing paused
- 09:15 Reporter asked for a photo of the rating platesent done
- 11:02 Photo received, serial number readcondition met done
- 11:03 Handover: engineer · schedule a visitwho · condition · action done
- 11:03 Customer asks for a visit todaydate needs a decision waiting for you
Sample log, fictional data. Scope, rules and stopping points are agreed in the process map.
The limits are part of the system.
If the data is incomplete or contradictory, or the case doesn’t fit the rules, the system doesn’t guess. It flags an exception and passes it to a person. That isn’t a failure — it’s a checkpoint.
The system can
- collect the minimum context of a request
- keep the original description with the time
- flag missing details openly
- ask the reporter for what’s missing
- hand the case over with a condition for moving on
A person decides
- urgency and the order of jobs
- the visit date
- quoting the repair
- anything outside the script
We cover this pattern in more depth on the blog
Service requests without the chaos: from form to named ownerOther processes we often start with
Enquiries and quote requests
An email describing a job → a brief with the gaps listed → a draft reply for approval.
See the processDocuments and invoices
A PDF or scan → a completeness check → a specific next step, or an exception with a reason.
See the processShared inbox
office@ → a working status and an owner → a handover with who, why and what to do.
See the processGot a process like this?
Describe it in a few lines. We’ll tell you whether it’s worth automating, where to start and what to leave alone.
Or call +44 7822 000220 · email info@sitco.uk