Client
A three-site franchised main dealer group in Scotland, selling several hundred cars a year and running sales, servicing, MOT, and manufacturer warranty work across all three sites.
Case study
Multi-Site Risk Agent for a franchised dealer group.
Three sites, three systems each, and not one of those nine reports could show a manager what was happening across all three. Here's what was built, and what it catches every morning now.
Data sources
Three systems per site: the dealer management system used by sales and accounts, the workshop control system that feeds it, and the manufacturer's parts ordering system. Nine scheduled reports to begin with, now one per site, keyed on job ID only.
Nine reports, no group view
How it used to be done: each site manager watched their own work in progress, in their own site's systems.
The three systems do talk to each other, and the workshop control system feeds the finance side. But none of them could report across all three sites. Every view was single-site by design.
Anyone wanting the group picture opened nine reports and held the comparison in their head.
That works while every manager is on top of their WIP. When one isn't, the gap only shows up if somebody is already looking across all three sites at once. Nobody was.
What was built
The obvious build was direct API access into all three systems. That was also the build that would have taken longest to get moving, so it wasn't the one to start with. What every system could already do was produce a scheduled report.
Those reports are keyed on job ID, so the whole workflow runs without customer names, addresses, registration numbers, or VINs. It never needs them. The agent reads job ID, job value, elapsed hours, clock-on count, and parts ordered against the job.
What goes wrong
Two of the losses, both on a clock.
Plenty slips when nobody is looking across the sites. These two have a deadline, so a system can catch them before it passes.
Parts that can't be returned
A part that doesn't get fitted has to go back inside 14 days.
Push the customer's appointment out three weeks and that window closes quietly. By the time anyone looks, the customer has gone elsewhere and the part is yours. A non-standard one can be a four-figure item sitting on a shelf.
Warranty claims filed too late
A claim has to be in within 10 days of the last clock-in.
Miss it and nothing about the job changes except who pays for it. The work was done. The car was fixed. The technician's hours went on the clock either way.
The claim is simply no longer recoverable, and the labour comes out of your own margin.
Neither failure announces itself. Both are quiet, both are recoverable right up until the day they aren't, and nobody finds out until well after the window has closed.
The part that made it work
Three reports per site, down to one.
Each site could produce three reports. Between them they held everything needed.
The main system report carried most of it. What it didn't carry were the two dates the deadlines count from: the last clock-in, and the last parts activity. Those sat in the workshop control report and the parts report.
The obvious build is to pull all three, for every site, and stitch them together.
This one doesn't. It reads the main report only, and keeps yesterday's copy beside today's. If elapsed hours have gone up, somebody clocked on. That is the warranty clock restarting. If the parts value has moved, there has been parts activity against the job.
Nine feeds become three. One per site.
The other two reports were never wrong. They were just two more things to pull, reconcile, and keep running every day. That is the work that quietly stops getting done.
What it does now
One list, across all three sites.
Today it is a dashboard. The regional manager opens one prioritised list: jobs approaching the 10-day warranty deadline, parts approaching the 14-day return window, and jobs that have stopped moving.
Each flagged job says what changed, which site it belongs to, which deadline it is running against, and how long is left.
The agent doesn't close claims, return parts, or chase customers. It puts the job in front of a person while there is still time to act on it.
Things are already being caught that would previously have been missed. Some of that is simply because the work is now being watched. That is worth saying plainly, rather than dressing it up as a performance figure. Attention was always the thing in short supply. The agent makes it cheap enough to sustain.
Where it goes next
From a dashboard someone opens to a message that finds them.
A dashboard still depends on somebody remembering to look.
Starting there was deliberate. It gives time to confirm the agent is watching the right things, and flagging them for the right reasons.
Once that confidence is there, the intention is to turn it around. Rather than someone opening a dashboard, the agent messages the regional manager by email or WhatsApp when something needs attention.
Further out, the same view can go down to each site manager. Not as a way of checking up on them, but as a tool of their own: the thing that catches what a busy Tuesday would otherwise let slip.
KinAct AI's workflows are built to remove repetitive manual work, not to replace human judgement. The goal is to free up a capable person's time by handling the gathering, structuring, and drafting of information, while keeping human review in the loop for all final decisions.
Built without exposing customer data
The whole workflow runs on job IDs. No customer names, addresses, registrations, or VINs are read, sent, or stored. That wasn't added afterwards. It is how the reports were specified, so the agent only ever receives the fields it needs.
Why it matters
Nothing here was hidden. Every system reported its own part of the picture accurately.
It was hard to see because seeing it meant pulling three reports for each of three sites and holding the comparison in your head, every day. Information that is spread out gets checked when there is time.
The agent doesn't make the decision. It makes the decision visible while it is still worth making.
Same shape, different operation