The conversation is a rich record that nobody can act on
A customer explains, over several messages and a call, that delivery has slipped twice, that the second delay was avoidable, and that they will decide about renewal in six weeks. The exchange is complete, candid and specific. What emerges at the end is usually a case note summarising the topic and a category selected from a list, neither of which tells anyone what to do or whether it was done.
The consequence is that service organisations can report how much they handled and very little about what they resolved. Escalations are counted, satisfaction is surveyed, and the actual question — did the customer's problem stop — is rarely answerable from the record. Most of the work that genuinely matters happens outside the system: a delivery rebooked by a planner who happened to see the message, a credit agreed by somebody who read the thread.
Three things a resolution needs and a note does not carry
- An action with an owner and a date, written down rather than inferred from a summary of a topic.
- A commitment with a reason attached — why the customer was given this response, and on what basis — so that a colleague can repeat it without reopening the discussion.
- Evidence of outcome, captured at the point the action was taken, separate from the evidence that the action was requested.
These are modest requirements. They are missing because the case record was designed to serve the agent's memory and the reporting layer, and neither of those needed the business to know what happened. The result is a service function that cannot learn, because the outcome data does not exist to learn from.
Priority is set from tone rather than consequence
Queue order is usually driven by arrival, by customer tier, and by how urgent the message sounds. None of these tracks consequence. A politely worded message from a large account describing a billing error that will become a dispute ranks behind an irate message about a delayed parcel, while a routine query about a service that has been down for three days may sit untouched because nobody read it as urgent.
The missing inputs are ordinary and mostly already held elsewhere: which service is affected, whether the customer has an entitlement, how much the account is worth, whether the same fault has been reported by others this week, and what the regulatory or contractual clock says. Priority is a policy, and like any policy it produces the wrong answer unless it is written down.
Ownership is ambiguous at precisely the moment it matters
Frontline agents handle the contact. The fix frequently sits in another department — a delivery rebooked by logistics, a credit raised by finance, a product defect investigated by engineering. At that point the case usually sits, because there is no mechanism that transfers it with an owner attached and a commitment about who tells the customer.
| Moment | What is missing | Consequence |
|---|---|---|
| Contact taken | A structured record of the actual request | Work is reconstructed from memory later |
| Routed to another team | A named receiving owner | The case waits and nobody is accountable |
| Customer promised something | The promise, its date and its basis | Silence is interpreted as agreement to be escalated |
| Action taken | Confirmation captured at source | Resolution is asserted rather than evidenced |
Ownership also fails in the opposite direction. A case that spans three departments can have three people each waiting for another, because no single owner was ever named for the outcome as a whole. Naming the owner of the customer's problem is different from naming the owner of each task, and the second does not produce the first.
Resolution is a status, not a verified outcome
Closing a case records that someone closed it. In most service operations, resolution rate, average handling time and first-contact resolution are the headline numbers, and all three can be improved by changing how cases are recorded rather than by improving service. This is the measurement problem that keeps a genuine improvement invisible and a cosmetic one visible.
The alternative is to define resolution as a condition checked against something outside the case: the replacement has shipped, the credit has appeared on the next statement, the configuration change is confirmed by the customer's own usage, the complaint is withdrawn. Those checks are usually trivial to express and occasionally hard to obtain, because they require the service organisation to talk to the teams that complete the work. The common reason they are not done is that they make the failure of another team visible, which is precisely their value.
What should not be delegated
Reading a conversation and extracting the request, the commitment and the missing information is well suited to delegation, because the input is unstructured and the output is a proposal for a person to confirm. What must not be delegated is the outward communication itself. An apology, an admission of fault, an offer of compensation and an explanation of a policy are commitments made to another party under pressure, and they are the point at which service organisations lose money and credibility.
What to start with on Monday
- Sample fifty recent cases and record, for each, what was requested, what action was actually taken, and by whom.
- Identify the cases where the customer had to chase again, and classify the reason the first response did not resolve them.
- Define the fields a service case must carry: the action, its owner, its date, and the commitment made to the customer with its basis.
- Write the priority policy in terms of consequence rather than arrival, and name who may override it.
- Name the owner of a case that crosses departments, separately from the owners of each task.
- Agree the resolution measures and the baseline before changing the case record.
The measures worth having are the proportion of cases with a recorded action and owner, cases needing a second contact for the same reason, the interval between a promise and its evidence, and the share of closed cases whose resolution was confirmed rather than asserted. The engineering that turns a conversation into a traceable action is covered in enterprise AI deployment, and the closely related problem of keeping a record consistent across systems appears in finance reconciliation.