The Systems Diagnostic · in detail
The long version, for the person who has to sign it off. Why we diagnose first, the two weeks end to end, what happens at the workshop, how the one-on-one interviews run, 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 takes two weeks, ten business days from the workshop to the Diagnostics Review, quoted to the size and complexity of your business, from A$3,900. The workshop, in person or online, builds the diagrams of how your business runs, signed off by your senior people. Over the following days, one-on-one interviews with the principal and the owner of each shortlisted workflow capture each workflow in detail.
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 structured review of how the work in your business is done day to day, including where that differs from the org chart. It exists because most businesses that know AI should be helping cannot say 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, with no obligation to build anything afterwards, and everything it produces is yours to keep. It is quoted to the size and complexity of your business, from A$3,900: see the overview page.
Three sources of evidence feed it: the workshop, the one-on-one interviews, and your own records. Each one checks the others. Where two of them disagree about the same piece of work, we look into it, because that is often where the main findings are.
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 works, and nobody measured whether the problem it solved was the expensive one.
The underlying problem: in most businesses, nobody can say where the time goes. Owners estimate. Staff estimate differently. The org chart describes roles, but the waste is in workflows, in handoffs, and in the gaps between systems. Buying technology before measuring that means choosing a fix before the problem is known.
So we diagnose first, and we charge for it, because a paid diagnosis carries obligations a free audit doesn't: evidence from your own records and people, a document you own, and recommendations we have to stand behind at your desk, in writing, with the working shown. If the diagnostic finds that the right 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 in writing before you agreed to a build.
Ten business days from the workshop to the Diagnostics Review, whatever the size of your business. Every date is booked at onboarding, before the clock starts, so you know when everything happens. If you need to move a date, the clock pauses until the new one.
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 on Teams, any time before the two weeks start. The agreement is signed, and we book the workshop, the interviews and the Diagnostics Review in the calendar, live on the call. You nominate who attends the workshop and who owns each workflow.
Education first, then the workshop that builds and endorses the diagrams of how your business runs. In person in one day, or online in two sittings on days 1 and 2. Session by session below.
The principal and the owner of each shortlisted workflow, usually 3 to 6 people, run in parallel. Every shortlisted workflow described in detail. How they run.
Each workflow is checked against the diagrams your senior people signed off, rated on how much it matters, given a dollar value by one method, and priced. The report arrives 48 hours before the review, so you read it at your own desk first.
Ninety minutes. The one decision point. What happens in the session.
The intentLeave with diagrams of how your business runs, drawn by your own people and signed off by your senior people. Everything we look at afterwards is checked against them, so they have to be right, and they have to be yours.
In person wherever that is practical, which is South-East Queensland by default: one full day on site, run as a series of sessions. Online, elsewhere or if you prefer: two sittings, the education session on day 1 and the workshop on day 2. The schedule is set around your business at the onboarding call. The sessions always run in the same order, and education always comes first.
Businesses are organised by roles, and automation works on workflows: a sequence of input, process and output. The sessions turn the roles into workflows.
Before anyone maps anything, the team learns to judge its own work with the same rules we use: what AI can and can't do today, what makes a workflow worth automating, and the four ways we put a value on a workflow. When your team shortlists later in the day, they're applying the same tests we will.
The difference between roles and workflows, then the team splits into three groups: acquisition (everything that gets the business work), delivery (everything that delivers it), and operations (everything that runs the business internally).
Each group draws a diagram of its part of the business: how the work comes in, gets done and is run day to day, as a small number of blocks, drawn by the people who do the work. It includes what happens when something is turned down or lost, because every approval can say no and every sale can fall through. Each group presents and the other two question it. Where they contradict each other, we record it and leave it for later: those contradictions are often where the main findings are.
Each group lists the recurring work that takes up its week, shortlists it against the criteria taught in the morning, and narrows the shortlist in discussion with everyone. Workflows the group can't agree on are dropped at this stage.
Every shortlisted workflow becomes a step-by-step flow chart on butcher's paper: who does it, what systems it uses, where it goes wrong. Each chart is specific, and every sheet is photographed before it is taken down.
Your senior people sign off the function diagrams before the workshop ends. This matters more than anything else the workshop produces: every workflow is later checked against these diagrams to see how much it matters to the business. Then the interviews are confirmed by name before anyone leaves, with what happens next, by whom, by when.
Practical notesWe need a room per group from mid-morning. One room with three tables also works. A single whiteboard is not enough. Online, each person joins from their own screen. Either way, education runs before the workshop, because the workshop uses the terms it teaches.
The intentFind out what people do not say in a group. The detail a build depends on is in the workarounds, the exceptions, and the things people don't write on a form or say in front of colleagues.
Over days 2 to 7, we sit down one-on-one with the principal and the owner of each shortlisted workflow, usually 3 to 6 people, run in parallel. Not everyone who attended the workshop is interviewed.
Each interview follows a set list of questions, using the diagrams your team signed off. Where the person's time goes across acquisition, delivery and operations. Who hands work to whom, and what moves between them. The recurring tasks, the friction, the failures, the tools.
Answers are named, because we need to be able to ask follow-ups. They are confidential: themes go into the Diagnostics Report, names are left out, and the interview is never used as a performance review. If an interview date moves, the two-week clock pauses until it happens.
During and after the interviews, each shortlisted workflow is described at the level of detail a build needs: the steps in order ("open this, copy the client reference, paste it there" is 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 how it runs when things go wrong as well as when they go right, because a workflow described only for the normal case gets built only for the normal case.
We ask how the work is done. Working out what to automate is our job.Workflows create value in four different ways, so each workflow gets the one method that fits how the work is done. 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. Fits when a person was doing the whole task on a known cadence. It does not fit when the automation runs far more often than a person could.
When it applies: a person was doing the whole task, regularly, and the automation frees that time. Your hours, your loaded rates, with the working shown. It applies to many workflows.
Method two
Before automation
Post automation
Presented as an increase in capacity, or the equivalent value created. Used when the new capacity can be used to increase throughput, often where the process was a bottleneck, and when the automation removes waiting time while human input time stays the same.
When it applies: the process was the bottleneck, and removing it means more work gets through. We only count capacity that can 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 the value comes from having outputs that are always up to date. A labour saving understates this kind of work, because the automation runs far more often than a person ever could.
When it applies: the value comes from having the output at all, kept live and current. For example, reporting that was done quarterly because doing it weekly by hand cost too much. We value 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 reduction in failures or an increase in success rate. Used when the work is cheap to do by hand, so a time saving would not show its value. The value shows up as more customers won back, less rework and fewer mistakes reaching clients.
When it applies: the task is cheap to do but expensive to get wrong. A four-minute task looks worthless on an hours count, and can still be the most valuable thing on the list if those four minutes are where a compliance certificate gets missed. Shown as a rate. We do not convert it into an invented dollar figure.
Worked examples. The figures are illustrative and do not come from client work. 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 you read every number and every price at your own desk before the meeting. It is written as a set of findings.
| Section | What it contains |
|---|---|
| Executive summary | The short version on one page: how many staff answered, what we analysed, and the main findings. Then our recommendation in one line. |
| What your team told us | Verbatim and anonymised, including the parts that aren't about automation. Where several people named the same task, where they disagreed (usually a sign the work is done differently from person to person), and how your team feels about AI. |
| The friction map | Where the week goes: each friction point with its hours and its indicative annual cost, linked to the part of the business it belongs to, split into what is worth automating, what needs a process fix, and what needs neither. |
| Everything we found | Every workflow worth automating, ranked, including the ones we don't recommend building yet, and why. Each shows the part of the business it serves, the hours it takes, and which of the four methods values it. |
| Tools and subscriptions | What you pay for now, which tools overlap, and when each one renews. We flag these and change nothing: cancelling anything is your call and your timing. |
| The plan | The recommended order over the next 12 to 24 months, in three groups: now, next and later. Items lower down stay on the list for later. |
| Recommended builds | Every recommended build ranked by estimated return for the price, with each item's indicative value and its own price side by side. |
| The build order | What we recommend building, item by item, ranked on estimated return for the price, with an estimated price for each, so you see it on paper before the session. |
| 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 forgotten. |
| Appendices | A brief for each workflow; your tools and subscriptions; a summary of the data and how items were ranked; and the Baseline Record, a dated record of how things run today. |
The report is charted from your own numbers, and the charts are built so you can check and challenge them. Where each person's week goes. The work map, drawn over your org chart, because the work does not follow the org chart. Spend against use for every tool you pay for: a tool with real spend and almost no hours of use is flagged. And the build order as a picture, value against complexity, so you can discuss the order with your own team from one page.
The last appendix records how things run today: hours per task, how long work takes, software spend, even your team's starting attitude to AI. It comes from your records where they exist and is marked as an estimate where they don't. It is dated and fixed at the Diagnostics Review, and never changed afterwards. Any claim about what a build changed is measured against that page. If you take Evolve, we re-measure against it at day 90, each quarter and at month twelve.
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 discussion of a document you have both read.
The session covers, in order: what your team said, read back to you; the friction map; and each recommended build, with its numbers explained and adjusted on the spot if something doesn't match how you run. Then you agree the build order, starting with the best estimated return for the price.
The session ends with one decision, and there are three ways to take it:
If you build, three things are put to you together: the items you choose, priced from the report's estimates, how you want to pay for it, and Evolve, quoted against that build. We make the offer once in the session, confirm it once in writing as a delivery engagement for you to sign, 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 fixes what will be built before the build starts, the system is tested on your real data, and your team is trained on it. Most builds are live within weeks. Builds start from A$5,000, paid up front or monthly.
Evolve is the optional monthly plan that follows the build. Each month it builds the next items on your Diagnostics Report list, each priced and ranked by estimated return for that price, and it covers monitoring, a monthly session with your team and the Monthly Status Report. It is quoted at the review against your build order. If you decline it, everything is handed over on your own accounts.
If you're not ready, the report stays yours: the diagrams, the baseline and the ranked order stay valid. Some businesses build the week after the review; some come back two quarters later. Either is fine.
No, and we say so up front. Answers are named because we need to be able to ask follow-ups. They are confidential: themes go into the Diagnostics Report, names are left out, and nothing anyone tells us appears in any performance review.
In person wherever that is practical, which is South-East Queensland by default, in one day. Elsewhere, or if you prefer, online in two sittings on days 1 and 2. The two weeks are the same either way.
Every date is booked at onboarding. If you move one, the two-week clock pauses until the new date, and the rest of the schedule moves with it.
Very little. A fifteen-minute onboarding form, a room per group on the day (or a screen each, online), lunch if we're on site, and your subscription list, which whoever does your books can send us. Most of the work is done in the sessions. The most useful thing your team can do is give plain, specific detail.
The nominated team gives the workshop: one day on site, or two online sittings. Each interviewed person, usually 3 to 6 of them, gives roughly forty-five minutes to an hour. The principal gives the onboarding call, an interview, and the ninety-minute review.
The full Systems Diagnostic is quoted to the size and complexity of your business, from A$3,900, ex GST. It is invoiced at booking (see the Diagnostic overview). Everything you might build afterwards is priced per item in your Diagnostics Report before you agree to a build.
Yes, or we run it online. SEQ metro is included in the price. Further afield, the workshop runs online in two sittings, or in person with travel 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.
For a business with many teams, many systems or compliance obligations, the full Systems Diagnostic, from A$3,900. The first step is the same short call.