A missed call should leave a case behind, not a vague promise to ring back. That case needs a reason for the call, the caller’s details, an owner, a deadline and a status. The phone is rarely the real problem. It rings while reception is serving someone at the counter, while a mechanic can’t take their hands off a car, or while someone in the office is trying to finish something important. The problem comes a moment later: nobody knows what is supposed to happen with that call.
After a missed call, a business usually ends up with one of three things: the number alone, a brief note, or a message kept in the head of whoever said they would ring back. That is not enough for the matter to have an owner, a deadline and an end point.
In short
– A missed call should become a case, not a vague promise to call back.
– A case needs the reason for the call, minimal contact details, an owner, a deadline and a status.
– Automation can collect information and pass the matter on, but it should not confirm anything the business cannot check.
– The first version should handle one simple category of call; everything else should go to a person.
The article Automation doesn’t start with AI. It starts with one process. explains why it pays to start with a single process. Here we go straight to practice: what a case should look like after a call nobody answered.
A missed call should end in a case, not a note
The rule is simple: the call should leave a record that someone can act on without replaying the conversation from scratch.
It does not need to be a full CRM or another screen to tick through. A first version needs one place that answers five questions:
| Case field | Why it matters |
|---|---|
| Reason for the call | Tells a booking request apart from a question about status or a complaint. |
| Callback details | Without them, “we’ll call you back” is just optimism. |
| Short context | The person picking it up doesn’t have to ask the customer for the basics again. |
| Owner | It is clear who is responsible for the next step. |
| Deadline and status | The matter doesn’t sit in a queue indefinitely. |
This is a small brief after the call: a short summary that is enough for the right person to take the next step. It is not a transcript of every sentence. The aim is that the next person doesn’t start with: “Hello, what was your call about?”
From call to answer
A short route with a named owner.
- Briefreason for call + number
- Queueowner + deadline
- Replycontact + status
Don’t leave it at a promise to ring back.
What can an automated system confirm to a caller?
Handling missed calls only works if it has limits. Either the system or the person taking the request has to know what it can do straight away, and what it must not pretend to know.
What it can do in a simple case
- say that the business will call back;
- ask for the reason for the call;
- collect a name, number, preferred time and a short description;
- save the request in an agreed queue;
- pass the matter to the right role;
- confirm that the request has been received.
What it should not confirm without data
- final availability of a slot;
- a price that needs an inspection or more detail;
- a status that isn’t in the current system;
- a specialist answer;
- an exception the business hasn’t described.
This isn’t caution for its own sake. It is the condition that stops faster handling from creating a bigger problem. If the question goes beyond the simple scenario, the right outcome is a case with context, passed to a person.
On its AI phone assistant page, sitco describes voice AI as a way to handle calls and pass matters on. In practice, start with a precise agreement on what the call covers, not a list of every question a customer might one day ask.
Three queues instead of one ‘call back’ inbox
Not every call should go to the same person. When everything lands in one inbox, the most urgent case can get lost next to a request for a simple piece of information.
The first split doesn’t have to be complicated. For many businesses, three categories are enough:
1. Booking or new service
This queue collects requests to book an appointment, take on a service or make a first contact. It matters that the handover includes not just the phone number but the scope and the preferred time. The person calling back shouldn’t have to dig through notes to work out what the call was about.
2. Status of an existing job
The customer asks about an order, a repair, a document or an earlier request. The most important things here are the reference number, the details needed to find the case, and a clear rule: if the information can’t be confirmed, the case goes to the case owner, not to whoever happens to pick up the phone.
3. Unusual or urgent enquiry
This queue is for anything beyond the simple scenario: a complaint, a problem needing a specialist, an unclear description or a matter that can’t be assigned. Its job is not to solve the problem automatically. It is to give the problem a visible status and a person who will take it on.
If the business has other real divisions, use those instead of these three. The categories are not decoration for a diagram. They should reflect how the business actually works.
Three queues instead of one inbox
Each category leads to the right role.
- New serviceBookingscope + preferred time
- Existing jobStatusreference + owner
- Urgent or unclearExceptionperson + context
The queues should match real work.
Who owns the queue, and what does ‘closed’ mean?
The biggest difference between a note and a process isn’t the technology. It is that someone is responsible for the state of the case.
For each queue, decide:
- Who takes the request — a named role, not “someone in the office”.
- Who calls back — it can be the same person or a specialist.
- When the case returns to the queue — for example, after no contact or missing details.
- What “closed” means — the customer got an answer, a time was agreed, or the matter was handed over with confirmation.
- What gets recorded for an exception — a short reason, the next owner and a date for action.
Closing has a clear condition
The owner knows the next step.
Are the details complete?
- NoClarify the details
- ExceptionPass to a person
- YesCall back and mark as closed
This pattern shows up in approval flows. Microsoft’s documentation gives an example of passing a request for approval and recording the decision and a comment (Microsoft Learn: approvals). That is not a recommendation of a specific tool, nor proof that every call needs approval. It is a useful reminder that an exception should get a next path, not disappear outside the system’s scope.
What does a minimal first version look like?
The first scenario should be dull. That’s a compliment.
An example for a service business:
- The system takes a call outside the team’s hours.
- It explains that it can’t confirm an appointment on the call, but it can take a request for a callback.
- It collects a name, number, type of service and preferred time.
- It creates a case in the “booking or new service” queue.
- It assigns the case to the role responsible for calling back.
- If details are incomplete or the customer asks something outside the scope, it marks the case “needs clarifying”.
This scenario doesn’t replace reception, sales or a specialist. What it prevents is a customer having to ring back just to leave their number again.
How do you know a callback queue is working?
You don’t need a dashboard to see whether a new way of working makes sense. Before you start, record a baseline, then track a small number of measures linked to the purpose of the service. GOV.UK recommends exactly this approach: set a baseline, choose measures that follow from the goal, and compare them over time (How to set performance metrics for your service).
For a callback queue, these might include:
- number of requests with complete details;
- time to the first callback;
- number of cases where the customer had to explain the basics again;
- number of requests placed in the wrong queue;
- number of cases flagged as exceptions.
These are suggested measures, not benchmarks. There is no single correct number for a garage, a dental practice, an accountant’s office or an online shop. What matters is that the business knows its starting point before launch and what it wants to improve.
Where does context get lost after a call?
In phone handling the problem rarely starts with the ring itself. It starts in the handovers:
- the number is saved, but there is no reason for the call;
- there is a description but no owner;
- there is an owner but no deadline;
- there is a deadline but nobody knows whether the customer got a reply;
- the matter needs a specialist but returns to the general queue.
Review these five handovers during the pilot. If context disappears between the call and the next step, adding more answers to the assistant won’t fix it. The handover has to be fixed first.
Where to start: one queue first
You don’t need to redesign your whole phone handling. Choose one queue, one simple scenario and one person who will confirm that cases are being picked up. The rest can carry on as before until the first route is clear.
If you want to walk through this with a real example, send us an enquiry. Bring one call that currently ends in a note or a “we’ll call you later”. That is enough to see whether it can become a case with an owner and an end point.