The Systems Diagnostic · in detail
The long version, for the person who has to sign it off. Why we diagnose first, the sessions end to end, exactly what happens on the on-site day, how the one-on-one interviews run, what Zed does through the week, how the numbers are calculated, and what the Diagnostics Report contains. If you want the short version first, read the Diagnostic overview.
In short. The Systems Diagnostic is about two weeks of measurement inside your business, at a fixed, published price. One on-site day builds the diagrams of how your business actually runs, endorsed by your own senior people before the day ends. In the days after, one-on-one interviews capture each workflow in detail, and Zed, our time-study agent, measures where the hours actually go through the week.
It ends with the Diagnostics Report, built from your own team's answers, with every recommended build individually priced, sent 48 hours before the Diagnostics Review: the one decision point. Build, trim, or take the report and stop. Nothing beyond the diagnostic is ever invoiced unless you order it.
The Systems Diagnostic is a measured audit of how your business actually runs, not how the org chart says it runs. It exists because most businesses that know AI should be helping can't say, specifically, where. Nobody has measured where the time goes, so every AI decision is a guess. The diagnostic replaces the guess with evidence.
It is a complete piece of work on its own: bought outright at a fixed, published price, with no obligation to build anything afterwards, and everything it produces is yours to keep. The current price by team size is on the overview page.
Three sources of evidence feed it: the on-site day, the one-on-one interviews, and the Zed Time Study. Each one checks the others. Where two sources disagree about the same piece of work, the disagreement is usually the finding.
Most AI projects in small businesses fail the same way. A tool gets bought because it demonstrated well, or because a competitor mentioned it. Six months later it sits unused, because it was never fitted to how the business actually works, and nobody measured whether the problem it solved was the expensive one.
The uncomfortable truth underneath: in most businesses, nobody can say where the time actually goes. Owners estimate. Staff estimate differently. The org chart describes roles, but the waste lives in workflows, in handoffs, and in the gaps between systems. Buying technology before measuring that is prescription before diagnosis.
So we diagnose first, and we charge for it, because a paid diagnosis carries obligations a free audit doesn't: measured data instead of a sales conversation, a document you own instead of a pitch, and recommendations we have to stand behind at your desk, in writing, with the working shown. If the diagnostic finds that the honest answer is a small fix, or none, the report says so.
The result is that any money you spend on building afterwards is spent where the evidence points, in an order your own team helped set, at prices you saw before you committed to anything.
Four steps over about two weeks, after booking and a short onboarding. The dates are locked at onboarding, so from the first week you know exactly when everything happens.
Invoiced at booking. You get a welcome note, a calendar link for the onboarding call, and a short onboarding form: a fifteen-minute task for the principal.
Sixty minutes, within five business days of booking. We lock the on-site day and the Diagnostics Review in the calendar, live on the call. You nominate who attends the day, and we agree the time study with you before your staff hear about it.
One full day on site, run as a series of sessions: education first, then the workshop that builds and endorses the diagrams of how your business actually runs. Session by session below.
In the days after the on-site day. The staff questionnaire, conducted person by person, and every shortlisted workflow described in detail. How they run.
Five to ten business days. Zed measures where the hours actually go, fills the gaps in what we know, and takes what comes up through the week. What Zed does.
Everything is coded against your endorsed diagrams, assessed for criticality, credited by one ROI method each, and priced. The report lands 48 hours before the review, so you read it at your own desk first.
Ninety minutes. The one decision point. What happens in the room.
The intentLeave with an endorsed picture of how your business actually runs, drawn by your own people. Everything we assess afterwards is judged against that picture, so it has to be right, and it has to be yours.
One full day on site, run as a series of sessions. The exact schedule is shaped around your business at the onboarding call, but the sessions always run in the same order, and education always comes first.
The premise behind the day is simple. Businesses are structured by roles, but automation needs workflows. A role is not a thing you can automate; input, process, output is. The sessions make that conversion, honestly.
Before anyone maps anything, the room learns to judge its own work with the same rules we use: what AI can and can't do right now, what makes a workflow a genuine automation candidate, and the four ways we put a number on a workflow. When your team shortlists later in the day, they're applying the same tests we will.
Roles versus workflows, stated plainly, then the room splits three ways: acquisition (everything that gets the business work), delivery (everything that delivers it), and operations (everything that runs the business internally).
Each group builds the diagram of the key business functions under its heading: how the business makes money and runs itself, as a small number of blocks, drawn by the people who do the work. Reject paths included, because every approval can say no and every pipeline can lose. Each group presents; the other two question it; contradictions get recorded rather than resolved. They're usually the best findings.
Each group lists the recurring work that eats its week, shortlists it against the criteria taught in the morning, and argues the shortlist down in front of everyone. A workflow that cannot survive its own colleagues' questions will not survive a build.
Every surviving workflow becomes a step-by-step flow chart on butcher's paper: who does it, what systems it touches, where it breaks. Specific, not vague, and every sheet is photographed before it comes off the wall.
Your senior people sign off the function diagrams before the day ends. This matters more than anything else the day produces: every workflow is later assessed for criticality against the endorsed diagrams, not against what happens to annoy people. Then the interviews and the time study are scheduled by name before anyone leaves the room, with what happens next, by whom, by when.
Practical notesWe need a room per group from mid-morning. One room with three tables works; one whiteboard does not. Above about ten staff, we can run the education session by video earlier in the week so the whole day belongs to the workshop. Either way, education runs before the workshop: the afternoon assumes its vocabulary.
The intentGet past what people say in a room. The detail a build succeeds or fails on lives in the workarounds, the exceptions, and the things people don't write on a form or say in front of colleagues.
In the days after the on-site day, we sit down one-on-one with your people: the principal, and the people who own the shortlisted work.
The staff questionnaire runs through these interviews as a structured conversation against the diagrams your team endorsed. Where your time actually goes across acquisition, delivery and operations. Who hands work to whom, and what actually moves. The recurring tasks, the friction, the failures, the tools. Some people prefer to complete it in their own time instead, and that's fine: same questions, same fields.
Answers are named, not anonymous, because we need to be able to ask follow-ups. They are confidential: themes travel into the Diagnostics Report, names don't, and it is not a performance review. We don't draft anything until at least 80% of nominated staff have answered; below that, we move the review rather than write a thin report.
During and after the interviews, each shortlisted workflow gets described at the level a build can actually use: the steps in order ("open this, copy the client reference, paste it there" is exactly the level we want), the decision rules, the approvals, and the edge cases. What went wrong the last three times. The workaround everyone uses but nobody documented. We ask for the messy run as well as the clean one, because a workflow described only from its happy path gets built only for its happy path.
We are not asking what should be automated. That's our job. We are asking about the work.The intentReplace estimates with measurements. A questionnaire returns "about 30 minutes"; a time study returns "between 6 and 52 minutes across 41 occurrences". The first is a number; the second is a finding.
Everything from the interviews feeds into Zed, our time-study agent, working in your Teams. Through the study window of five to ten business days, Zed does three jobs:
An agent messaging your staff during their working day is workplace monitoring, whatever it's called. So we treat it that way, and it's agreed with you at onboarding before staff ever hear about it.
Where Zed isn't a fitSome workplaces, and some people, prefer a simpler instrument. A short manual timing log covers the same fields over the same window. Measured is measured; the report treats both the same way.
Workflows pay for themselves in four different ways, so we credit each workflow by exactly one of four methods. Picking which method applies is itself a finding about the work. The four are below, each with a worked example.
Method one
Before automation
Post automation
Presented as a reduction in time and cost, or as a saving per period of time. The simplest and most credible method when a real person really was doing the whole thing on a known cadence. Not used when the automation runs far more often than a human ever could have.
When it applies: a person was genuinely doing the whole task, regularly, and the automation hands that time back. Your hours, your loaded rates, with the working shown. This is the method most of your candidates will be credited by, because it's the hardest to argue with.
Method two
Before automation
Post automation
Presented as an increase in capacity, or the equivalent value created. Used when the new capacity can actually be used by increasing throughput, often where the process was a bottleneck, and when the automation doesn't reduce human input time but removes waiting.
When it applies: the process was the bottleneck, and releasing it means more work actually flows through. We only credit capacity that can genuinely be used. Doubling the throughput of a step that feeds a queue saves nothing, and the report says so when that's the case.
Method three
Post automation
Post automation · repeating
Presented as an equivalent value per time period. Used when value is realised by having access to live or recently updated outputs. Labour-savings arithmetic loses credibility the more often the automation runs, or where the task was deliberately done rarely because of other business constraints.
When it applies: the value is in having the output at all, live and current, not in the labour saved producing it. Think of reporting that was done quarterly because doing it weekly by hand was unaffordable. We credit it at what producing it by hand would have cost, for as long as the output stays useful.
Method four
Before automation
Post automation
Presented as a portion of reduced failures, or the increase in success rate: a rate, not a dollar. A workflow may be cheap to do manually, so time and cost savings miss the real value: more customers reactivated, less rework, less production downside.
When it applies: the task is cheap to do but expensive to get wrong. A four-minute task looks worthless on a time study, and can still be the most valuable thing on the list if those four minutes are where a compliance certificate gets missed. Credited as a rate, never converted into an invented dollar figure.
Worked examples with illustrative figures, not client results. Your Diagnostics Report runs this arithmetic on your own hours and rates, with the working shown.
Built from your own team's answers, printed and bound if we're on site, and sent 48 hours before the Diagnostics Review, so every number and every price is met at your desk rather than for the first time in a meeting. It reads like a finding, not a pitch.
| Section | What it contains |
|---|---|
| Executive summary | The short version on one page: how many staff answered, what we analysed, and the key findings, one of them usually a surprise. Then our recommendation in one line. |
| What your team told us | Verbatim, anonymised, unspun, including the parts that aren't about automation at all. Where several people named the same task, where they disagreed (usually a sign of process inconsistency), and how your team actually feels about AI. |
| The friction map | Where the week actually goes: each friction point with its hours and its indicative annual cost, tied to the block of the business it lives in, with an honest split between what's an automation candidate, what's a process fix, and what's neither. |
| The candidate inventory | Every automatable workflow we found, ranked, including the ones we don't recommend building yet, and why. Each carries the business block it serves, the hours it eats, and which ROI method credits it. |
| Tools and subscriptions | The one hard-dollar section: your subscription stack as it stands, what renews when, what overlaps, and what we're deliberately not touching. Flagged, never actioned. Cancelling anything is your call and your timing. |
| The roadmap | The recommended order over the next 12 to 24 months, in three bands: now, next cycle, later. Nothing is lost by being lower down, and nothing is re-priced by waiting. |
| What runs first, priced | The ranked order of what should be built first, with each item's indicative value and its own price side by side: the plan and the price list at once. Prices hold for twelve months. |
| The build order | What you can actually buy at the review, in writing, with nothing bundled, so the offer arrives on paper before the room, not in it. |
| What we left out | The ideas from the workshop and interviews we don't recommend, each with its reason, so nothing your team raised is quietly forgotten. |
| Appendices | A brief per candidate workflow; your stack and subscription ledger; the raw-data summary and ranking method; and the Baseline Record, your before-state, measured, dated and frozen. |
The report is charted from your own numbers, and the charts are built to be argued with. Where each person's week goes. The work map, drawn over your org chart, because the work does not follow the org chart. Elapsed time against hands-on time, from the timing data. Spend against use for every tool you pay for: a tool with real spend and almost no hours is an orphan. And the build order as a picture, value against complexity, so you can re-argue the order in front of your own team from one page.
The last appendix is the one that keeps us honest for the next year. It freezes your before-state: hours per task, cycle times, interruption counts, software spend, even your team's starting attitude to AI. Measured where we could measure, marked estimated where we couldn't, dated, and locked at the Diagnostics Review. Every claim anyone ever makes about what a build changed is arithmetic against that page, re-measured at day 90, each quarter, and month twelve. It never gets quietly re-based.
Ninety minutes with the principal, working through a report you've already read. Because the report went out 48 hours earlier, the session is a working conversation about a document in front of you both, not a presentation.
The session covers, in order: what your team said, read back plainly; the friction map; and each recommended build, with its numbers explained and adjusted on the spot if something doesn't match how you actually run. Then you set the order of what would be built first.
The session ends with one decision, and there are three ways to take it:
We make the offer once in the room, confirm it once in writing, and leave the decision with you.
What gets built comes from the report, and it isn't always one thing.
Either way, a short design session locks exactly what will be built before anything is built, the system is tested on your real data, and your team is trained on it. Most builds are live within weeks.
If you're not ready, nothing expires. The diagrams, the measured baseline and the ranked order stay true, and the prices in the report hold for twelve months. Some businesses build the week after the review; some come back two quarters later. Both are the deal working as designed.
No, and we say so up front. Answers are named because we need to be able to ask follow-ups, and because the interviews are conversations, not forms. They are confidential: themes and measurements travel into the Diagnostics Report, names don't, and nothing anyone tells us appears in any performance review.
No. It's opt-in per person, on named tasks, agreed with you at onboarding before staff hear about it, and anyone can revoke at any time without explanation. Zed captures nothing passively: no screens, no keystrokes, no mail. Where someone prefers not to use an agent at all, a short manual log covers the same fields.
Very little. A fifteen-minute onboarding form, a room per group on the day, lunch, and your subscription list, which goes to whoever does your books rather than to you. The heavy lifting is done in the sessions; the single most useful thing your team can be is boring and specific.
The nominated team gives one day on site. Each interviewed person gives roughly forty-five minutes to an hour, and time-study participants answer a few seconds of prompts a few times a day for a week or two. The principal gives the onboarding call, an interview, and the ninety-minute review.
The price is fixed, published by team size on the Diagnostic overview, and invoiced at booking. Everything you might build afterwards is priced per item in your Diagnostics Report before you commit to anything.
Yes. SEQ metro is included in the price; further afield, travel is recovered at cost (flights, accommodation, ground transport), quoted up front, with no mark-up.
Then you bought a diagnosis, and it was delivered. You keep the report in full, every item priced, useful whoever ends up building it, and nothing further is ever invoiced. That outcome is the deal working as designed, not a failure we need to manage you out of.
Two weeks, a fixed price, and a report you keep either way. If your business isn't a fit, we'll tell you on the first call.