Where is the time going? What three AI audits found before anyone mentioned a chatbot
Most AI audits start by asking where AI could help. Three recent audits of Singapore service businesses started by asking where the hours go. The answers pointed at repeated questions, slow handoffs and one-person approvals, not at a missing chatbot.
In The Effective Executive (1967), Peter Drucker wrote: "Effective executives, in my observation, do not start with their tasks. They start with their time." His method had three steps: record where the time actually goes, cut what doesn't need doing, then group what's left into usable blocks.
Most AI audits skip the first step. They open with "where could AI help?", get the answer "a lot", and write a proposal for a chatbot. Three weeks later someone finds out the real work runs through dozens of WhatsApp groups and a job system nobody is willing to leave.
In October 2026, Flareworks ran free AI audits for three Singapore service businesses: a 50-person home-repair group, a 10-person electrical and plumbing contractor, and a solo operator who runs workshops and classes. Each one started with Drucker's question instead of the AI one. In none of them was the biggest finding "you need a chatbot".
The wrong first question
"Where could AI help?" has no wrong answer, which is the problem. AI can be pointed at almost anything, so the question produces a wish list, and the loudest item on the list wins.
"Where is the time going?" has a number for an answer, and a number can be checked. It also forces three follow-ups that decide whether any fix will work:
- How often, and how long? Times a week and minutes each time. Not "constantly".
- Who does it, and who does it pass through? The chain of people is usually where the hours go.
- Where does the answer live? A shared drive, a chat group, or someone's memory. This is the constraint most tools fail on, and you can't see it on a call.
Owners rarely know these numbers offhand. So the audit asks them to count for a week.
How to measure it: the one-week question log
The simplest version is a log of every question that stops someone's work, kept in a shared spreadsheet or wherever your team already lives.
Log the question
Every time someone stops to ask something they need before they can carry on, write down the time, who asked, and the question in their words.
Log the path
Who they asked, and who that person had to ask next. A question that goes technician, then operations, then manager is three people's time, not one.
Log the wait
How many minutes passed before the asker could carry on, and what was waiting meanwhile: a customer, a technician on site, a quote.
Log where the answer was
In a document, in a chat, in one person's head, or nowhere.
Add it up on Friday
Group the questions by type and total the minutes, including everyone in the chain. Sort by hours, not by how annoying each one feels.
The arithmetic is where owners get surprised. Here's an illustrative example, not client data: a question that takes five minutes to answer, passes through two people and leaves a technician waiting fifteen minutes costs about 25 minutes, not five. Twenty of those a day is more than eight hours, or roughly one full-timer.
This log is different from the approval inventory, which records the judgment behind each yes or no. The log records the cost. The inventory records the rule. You'll want both, in that order.
What the three audits found
A 50-person home-repair group: the same questions, every week
Most of the group's Singapore staff are technicians in the field. Its job-scheduling system has been in place for more than 10 years, and the founder called it "almost impossible to pull out." The customer side was already handled well: automatic booking confirmations, an "on my way" link and a survey after each job. The founder keeps customer conversations human on purpose, even when that's slower.
The time was going somewhere customers never see. A technician on site needs an answer. He asks operations. Operations digs through the shared drive and the chat groups. If they can't find it, it goes to a manager, and sometimes up to the founder. The questions were ones like these:
- Which repair method applies here?
- Can this spare part be substituted?
- What's the approved price rule for this client?
- Which document has the latest answer?
A second stream of time went into the chat groups themselves: requests posted in WhatsApp and Telegram with no clear owner, so staff checked chats for status, chased people for updates and retyped requests into the job system.
The audit estimated both streams from the hand-offs the founder described, using the team's own numbers: about 30 technicians, each asking one question every one or two working days.
The biggest lines are people waiting and searching, not anyone typing an answer. None of it is customer-facing, so a first fix carries little risk, and the people asking for it are the ones stuck waiting.
A 10-person electrical and plumbing contractor: the interruptions
The owner paused our call three times in 30 minutes: a spare-parts delivery, a phone call and an urgent job. That interruption was the problem we were there to fix.
His time goes before the sale. An enquiry arrives on WhatsApp without the photos or model details needed to price it. Most jobs need a site survey before a fair quote. Equipment prices vary by model, so suppliers have to be checked. And only two people in the company prepare quotes, him and one other. By his own account, the work after the sale runs fine.
Every step waits for one of two people, so a quoting tool alone wouldn't help: the quote is the last step, not the slow one. His own questions on the call were about consequences, not capability: if two of his people disagree on who goes, who decides? Which AI sees his customers' data? What will it cost each month?
A solo workshop operator: the hours nobody had counted
She lists each event on several booking platforms, then logs into each one to copy sign-ups into a spreadsheet. An obvious candidate for automation.
The honest finding was that nobody knew how long it took. So the first recommendation wasn't an integration: time the job for one event, test a simple browser-based workflow on one platform, and measure the saving before building anything deeper. If the hours are small, a better spreadsheet is a fine answer.
The pattern
Across all three, the hours went to the same three places:
- Questions whose answers exist but aren't where the person is standing.
- Handoffs that wait for one or two people, usually the owner or a manager.
- Copying between systems that don't talk to each other.
The people absorbing those hours were never the customers. They were the managers, the owner, or the solo operator herself.
Why "PDFs plus a chatbot" doesn't fix it
The obvious fix for the home-repair group is to upload the manuals to a chatbot. But this isn't a search problem. The answer exists. It just isn't where the technician is standing, and part of it isn't in any PDF.
Company knowledge lives in three places a folder of documents misses:
- People. Two managers who both think they know the current rule.
- Exceptions. The substitution that's allowed for one brand and not another, the price rule for one client.
- Approvals. Who is allowed to say yes, and when the answer has to go to them.
A technician doesn't need an AI that summarises a long manual. He needs one reliable answer to one operational question, from approved knowledge, when he needs it. Without structure around that answer, the AI sounds confident while giving an outdated or unauthorised one. The real product is everything around the answer:
Before
PDFs plus a chatbot: every document uploaded at once, answers with no source, no way to tell which version is current, everyone sees everything, and it always gives an answer.
After
A knowledge base people can trust: one knowledge area with 20 to 30 approved documents, a source cited on every answer, a review date and an owner on every document, technicians see procedures but not client pricing, and it says "I don't know" and passes the question to a person.
The best first pilot is small. Pick the knowledge area that tops your question log. Approve 20 to 30 documents for it, with a named owner for each. Then test the system against the real questions your team asked last month, which is exactly what the one-week log collected. Record every wrong, uncertain and outdated answer before deciding whether it's fit to go wider.
AI can make company knowledge easier to reach. It can't make it trustworthy. That part is a management job, and someone inside the company has to own it.
"It saved my time, but not the company's"
The founder of the home-repair group had already tried AI herself. She uses ChatGPT in her own meetings, and it helps. Her verdict: "For me, it saved my time. Collectively as a company, no."
Her team had stopped bringing questions to her. They took them to the managers instead, who, in her words, take "the first filter". Her queue went down. The company's didn't. It moved. The audit's estimate shows the same shape: questions that reach the founder take 3 to 6 hours a month, while technicians waiting and operations searching take 110 to 275.
Eliyahu Goldratt made this point about factories in The Goal (1984): "An hour saved at a non-bottleneck is a mirage." In a small company the founder is often the bottleneck, so making her faster is genuinely worth doing. But once her queue clears, the bottleneck moves one step down, to the managers, and the same broken process keeps running.
Personal AI use doesn't add up to company value until someone fixes the handoff in between: where the question starts, who answers it today, and how many people it passes through first. Those are the columns of the question log, which is how you see the handoff that personal AI use hides.
This week's checklist
- Monday: set up the log with five columns: time, who asked, the question, who answered (and who they asked), minutes lost including waiting. Log as it happens, not from memory.
- Friday: group by type, total the hours, and sort by hours.
- Then: for the top group, write down where the answer lives today and who owns it. If nobody owns it, that's your first fix, and it costs nothing. Writing down one process is the next step.
- Before any demo: keep 20 to 30 real questions from the log as your test set. Any vendor who shows you a knowledge-base demo should run it against those, not their own examples.
What comes after, from fixing the process to checking the machine's work, is in Audit, Optimize, Automate, Verify. The log is the first half of its first step.