When a provider answers this question with a presentation, the question is still open. A case is told differently: through the mechanism. Here is one of ours, the handling of inbound requests, which also happens to be the most transferable from one company to another.
The starting situation
Requests arrived through four channels: a website form, a generic mailbox, the phone, and a business messaging number. None of the four spoke to the others. Qualification happened from memory, follow up depended on whoever was available remembering it, and nobody could say how many requests had gone unanswered the previous week.
The cost was not in the handling time of a request. It was in the ones that fell through.
The breakdown
We split the process into six steps, deciding for each one who executes it:
- Reception. The four channels write into a single place, with the origin preserved. Fully automatic.
- Cleaning. Duplicate detection, phone and address normalisation, matching to an existing customer if there is one. Automatic, deterministic rules.
- Qualification. The model reads the request, extracts the subject, the urgency and the sector, and proposes a priority level with a one sentence justification. Automatic, but nothing is sent to the customer at this step.
- Reply. A draft reply is written from the internal knowledge base. It goes to a human on sensitive requests, and out directly on simple, frequent cases.
- Follow up. Scheduled automatically, cancelled automatically as soon as a reply arrives, capped in number.
- Closing and measurement. Every request ends in an explicit state, with its delays recorded.
Where the line sits
The rule we apply here is constant: the machine prepares, the human commits the company. Qualifying, summarising, drafting, sorting, reminding: the machine handles that alone. A contractual commitment, a negotiated price, a refusal, a dispute: a human validates. That line is not decided during development, it is decided during framing, process by process. We go into detail in a dedicated article.
What changed, in numbers
Three indicators were set before starting, and that is what makes an assessment possible: the median time to first reply, the share of requests unanswered after forty eight hours, and the human time spent per request. Without those three figures taken beforehand, any assessment would have come down to an impression.
We do not display generic percentages here: from one sector to another they mean nothing. What transfers is the method: measure before, measure after, on the same indicators, and accept that the result may be disappointing on one step and excellent on another.
An automation with no number before it has no result afterwards. It has a reputation.
What breaks, and how often
Three things break, and they break regularly. A programming interface changes format without warning. A model changes behaviour after an update and becomes more talkative or more cautious. And the company itself changes a business rule without saying so, because it was "only a detail".
This is why maintenance is not a side question: it belongs to the cost of the process, not to after sales service. We answer it in the article on maintenance.
How to check with a provider
Ask to see the real run, not the presentation: the steps, the exact point where a human steps in, the execution log, what happens on failure, and the indicators before and after. A provider who has put a process into production can open that screen in thirty seconds. A provider who can only show a video has not lied, but has not answered either.
