A repair operation running 27,000 jobs a year across Auckland, Hamilton, Wellington and Christchurch generates a lot of phone calls. Most of them were the same call.
Someone had handed over a broken phone. Days had gone by. They wanted to know where it was and when they would get it back. That was it. No complaint, no escalation, just a person without their device ringing to find out whether anything had happened.
The answer was almost always sitting in our ERP already. The job had a status. The status had a timestamp. Somebody in the call centre would look it up, read it out, and the call would end in ninety seconds. Twenty thousand times a year we were paying people to read a database field down the phone.
We built a system that sent the field before anyone had to ask for it. Automated SMS and email at every real milestone in the repair journey, plus a write-back into the insurers' own portals so their staff could see the same thing. Inbound call volume dropped by 40%.
This is what we did, why the sequencing mattered more than the messaging, and why the pattern is worth understanding now that AI can do the harder half of it.
Why does a repair operation generate so many status calls?
Because a repair is a black box with a person's daily life inside it.
Hand over a car and you can see it on the forecourt. Hand over a phone to an insurer and it goes into a courier bag and disappears into a chain you cannot observe: assessment, parts, workshop, quality check, dispatch. Every day of that silence raises the odds someone rings to check the thing still exists.
We could see the pattern clearly once we plotted it. Calls did not spread evenly across the repair. They clustered in the gaps. The longest gap by far was the parts wait, where a device that needed a component we did not hold could sit for days with nothing visibly happening. That silence produced calls the way damp produces mould.
There was a second caller nobody counts, which was the insurer. IAG and Vero had their own customers ringing them, and when those customers rang, the insurer rang us. One repair could generate two separate status conversations about the same database row.
What was that costing?
Call centre time is the obvious number and the least interesting one. At roughly ninety seconds of handling plus wrap-up per status call, several thousand of them a year is real money, but it is not the part that hurt.
The part that hurt was displacement. Every status call sat in the same queue as the calls that genuinely needed a person: the damaged-in-transit conversation, the second device failure, the customer whose claim was declined and who needed someone to explain why with some care. Those calls waited behind "where is my phone".
Queue time went up for everybody. Satisfaction went down on exactly the interactions where it mattered most. And the staff who were good at difficult conversations spent a large slice of their day reading out job statuses.
How do you decide which milestones to send?
The temptation is to send more. More updates, more reassurance, more touchpoints. That is how you train people to ignore you.
We used a simple rule. A message goes out only when the job's state has genuinely changed in the ERP, and only when the change answers a question the customer would otherwise ring to ask. No "we're thinking of you" messages, no progress bars that move without anything moving underneath.
That gave us a short list. Job created and courier pack on its way. Device received at the workshop. Assessment complete with the outcome. Parts ordered, with the expected wait stated plainly. Repair complete. Dispatched, with the tracking number. Each one a real event with a real timestamp, already recorded because the operation needed it internally.
The parts one earned its place through data rather than instinct. It was the least satisfying message to send, because it is the one that says "you are waiting and here is roughly how long for". It was also the single biggest reduction in calls, because it filled the longest silence.
What goes in the message?
Answer the next question before it gets asked. That is the whole content strategy.
A received message that says "we have your device" is worse than useless, because the immediate next thought is "and how long will it take". So the received message carries the expected assessment date. The assessment message carries the outcome and what happens next. The parts message carries an expected date and says what happens if that date slips.
We kept them short and stripped the reassurance language out. People waiting on a repair want a fact and a date. Anything else in the message is noise they have to read past to get to the two things they opened it for.
How did the insurer portal integration change things?
It closed the second loop, and it was the piece that took the actual engineering work.
The customer-facing messages handled the person holding the claim. They did nothing for the claims handler at IAG or Vero who was fielding the same question from the same person on a different day. Writing status directly into the insurers' portals meant their staff could answer without ringing us at all.
That is a less visible win than the SMS traffic and probably a larger one operationally, because an insurer-to-repairer status call is a longer, more structured conversation than a customer one. It also changed the relationship. A repair partner whose status is live inside your system is a different kind of supplier to one you have to phone.
The integration work itself was unglamorous. Field mapping, status vocabulary that did not match between three systems, retry logic for when a portal was down, and a reconciliation job that caught anything that failed silently. None of it is interesting to describe. All of it is the difference between a system people trust and one they check manually, which would have defeated the point entirely.
What broke, and what we learned from it
Two things, both worth knowing before you build something similar.
The first was status vocabulary drift. Our ERP had a status set built over years by people who used it daily, and it did not map cleanly onto what an insurer's portal expected or what a customer would understand. "Awaiting parts" meant four different operational situations internally. We had to collapse the internal detail into a customer-facing vocabulary of about six states and hold that mapping in one place, rather than letting each channel invent its own.
The second was that automated messages surface operational problems you were previously absorbing. Once every customer got told "parts ordered, expect five to seven days", the jobs that sat at eleven days became visible to the customer, and they rang about that instead. Which was the correct outcome, and it was still uncomfortable for a while. Telling people the truth about your timelines means committing to your timelines.
What did the 40% reduction actually change?
Two in every five inbound calls stopped happening. The queue that remained was almost entirely calls that needed a human being.
That is the number worth holding onto. Not the volume reduction on its own, but what it did to the composition of the queue. The call centre stopped being a status lookup service and went back to being what it was supposed to be, which was people handling the situations where judgement and care mattered.
Nobody lost a job over it. The work got harder in the sense that a larger share of it was genuinely difficult, and better in the sense that it was work worth doing. The same thing happened later with Smart Assess, where automating device assessment took the routine claims off the handlers' queue and left them the ones that needed a person.
There was a compounding effect we did not design for. Customers who got a parts-delay message before they noticed the delay themselves did not treat it as a failure. They treated it as being kept informed. The same slip, discovered by ringing up on day nine, was a complaint. The message did not change the repair time by a single day. It changed what the wait meant.
What does this pattern teach about AI now?
This was built in 2022 and 2023, with no AI in it anywhere. It was rules, triggers and integrations, and that is exactly why it is worth looking at.
The system worked because we had first done the boring part: mapping the operation into states that were real, agreeing a shared vocabulary, and being honest about what each state meant. Once that existed, sending a message on a state change was trivial. Firms that skip the mapping and go straight to the messaging end up with notifications that fire on nothing and mean nothing.
What AI changes is the half we could not automate. In 2023, a customer who replied to a status text with "that's fine but can you send it to my work address instead" hit a human, because parsing that reply and acting on it was beyond a rules engine. Now it is not. An agent can read the reply, work out that it is an address change, confirm the new one, and update the job.
That is the shift, and it is narrower than the hype suggests. The state machine, the milestone map and the honest timelines are the same work they always were. What is new is that the unstructured half, the replies and the phone calls and the awkward exceptions, can now be handled by software as well. AI made language programmable. The operations thinking underneath it did not change at all.
We build this kind of thing for firms in the insurance and property sector and across bespoke integration work generally. If your team is answering the same question several thousand times a year, get in touch.
Frequently asked questions
- How much does automating status updates reduce inbound calls?
In this case, 40% of inbound call volume across an operation handling 27,000 device repairs a year. The size of the reduction depends on how much of your current call mix is status enquiry. Pull a sample of a hundred recent calls and categorise them before you estimate, because most operations guess low.
- Which repair milestones should trigger a customer message?
Only state changes that answer a question the customer would otherwise ring to ask. In practice that is job created, item received, assessment outcome, parts ordered with an expected date, repair complete, and dispatch with tracking. The parts message matters most, because it fills the longest silence in the process.
- Do automated updates work without AI?
Yes. This system used rules, triggers and API integrations with no AI at all. The prerequisite is a set of job states that are real and consistently recorded. AI adds value on the other half of the problem, which is handling the replies and phone calls that a rules engine cannot parse.
- What is the hardest part of integrating with an insurer portal?
Status vocabulary. Your internal states, the insurer's states and the words a customer understands are three different sets, and reconciling them into one mapping held in a single place is most of the work. The rest is retry logic and a reconciliation job so that silent failures get caught.
- Will automated updates increase complaints about delays?
They make existing delays visible sooner, which feels like an increase at first. In practice a delay disclosed before the customer notices it reads as being kept informed, while the same delay discovered by ringing up reads as a failure. The trade is that you have to be honest about your timelines.