An example I made up.
Leong Wai Kit manages the claims team at a regional logistics company. Its head office is in Singapore, and it moves chilled and frozen food for supermarkets and restaurants across the region. When a customer says a delivery arrived spoiled, the claim comes to Wai Kit's team.
The team uses SpiderhunterAI every day. It reads each claim, matches it to the delivery and prepares the weekly list of claims to pay. The list goes to finance on Tuesday at 16:00.
On a Tuesday afternoon, a claims officer in his team held one claim back from the list. The customer was one of the company's largest. SpiderhunterAI had marked the claim ready to pay with this line: "This claim for spoiled frozen seafood is valid. The customer's photos and report match the delivery on 3 March. I am 92 percent sure."
Everything SpiderhunterAI had been given did match. What it hadn't been given was the truck's temperature log. The transport team keeps that log, and the claims system doesn't read it. The claims officer asked the transport team for it. The log showed the load at the right temperature all the way from the warehouse to the customer's door. That pointed to the customer's own cold room, after hand-over. On this evidence the claim was not the company's to pay.
The check took most of Wednesday. The customer's account manager complained that a promised payment date had been missed. The commercial director then asked Wai Kit why his team had held back a claim that the tool had marked as valid.
Wai Kit wrote back to the director the same day. He said the hold was his team member's decision, that he backed it, and why: the log showed the goods were cold at hand-over. He sent a copy to the account manager. Then he made one rule for the team. Every claim for spoiled chilled or frozen goods is checked against the truck's temperature log before it is paid, whatever the tool says. He also told the team, in writing, that a claim held for a check is never counted against the person who held it.
Three months later, the team has held six claims for a log check. The transport team sent every log within two days, and nobody has been asked again to explain a held claim.
What the manager owed the team
Nothing in that story is about a poor tool. SpiderhunterAI did what it was set up to do with what it was given. The part worth looking at is what Wai Kit did after that Tuesday, and what he could have done before it. The tool and the training are the part an organisation can buy. What a manager owes the team after that is a set of acts, and I'd describe them like this.
The first is saying which decisions stay with people. SpiderhunterAI prepares the list. A person still has to decide that each claim on it is paid. If nobody has said so clearly, a team can start to read "marked ready" as "decided", because that's what the screen suggests. A manager can write the line down: the tool prepares the work, and a named person decides these particular things.
The second is leaving time in the day for the check. If the list is due at 16:00 and the plan assumes the AI is right, the check is the first thing people drop on a busy afternoon. Time for checking has to be in the plan before the busy day arrives, because nobody has spare time on the day itself. That means agreeing with finance, or with whoever waits on the work, that a held item is a normal part of the week.
The third is backing a person whose check slowed the work. This is the one that costs the manager something. Someone senior is unhappy about a missed date. The easy reply is to apologise for the delay. Wai Kit replied in writing, on the same day, with the reason. If a team sees one check punished or quietly regretted, people may check less. If it sees one check defended in front of a director, they have a reason to keep checking. The defence has to name the check and what it showed.
The fourth is telling the team what to do when the AI is wrong. A person who finds an error may not be sure whose problem it is. Should they fix the item and move on, or tell someone first? A manager owes them a plain answer before it happens: hold the item and tell the manager the same day, with the reason written in the record. In the example, the rule about temperature logs was made after one held claim. The next person who finds a problem shouldn't have to decide the steps alone.
The fifth is reading some of the decisions, not only the output. A weekly total tells a manager how much was paid. It doesn't tell the manager whether anyone checked what needed checking. Once a month, a manager can pick a few claims and ask the person who handled each one what they looked at before they decided. The aim is to learn which checks are still happening and which ones have stopped, so the manager can fix the work rather than blame the person.
None of these five needs a new system. Each one needs a manager to act before the busy afternoon, and to act again after it. The tool will keep getting better at preparing the work. A person still has to decide whether the work is right, and a manager still has to make it safe for that person to check.
AI can draft the plan. It cannot decide whether the plan is right.
The example is made up, and so are its numbers. I measure nobody's team.
I give keynotes, briefings and workshops on this.