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 tracked the work in progress at their own site, in their own systems.
The three systems talk to each other, and the workshop control system feeds the finance side. What none of them could do was look across sites. Every report was built for one site at a time.
Seeing the group picture meant opening nine reports and holding the comparison in your head.
That works while every manager stays on top of their WIP. When one doesn't, the gap only surfaces if someone is already watching across all three sites. 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, and they can still be added. Feed them in and you get the exact date and time of every clock-on and every parts movement. Comparing two days of one report tells you the day something happened, not the hour.
Against a 10-day and a 14-day deadline, the day is enough. So the lighter setup is the one that runs: three feeds instead of nine, with the extra precision available whenever it earns its keep.
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.
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 as an early-warning list of their own: the jobs, parts, and deadlines most likely to need attention before the day runs away from them.
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. The reports are specified so the agent only 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