An AI workflow example
shown from start to finish.

The work before the workflow

In our demonstration, a technician finishes a visit, with a door closer replaced, a light that flickers and a handrail that has come loose, and calls or messages the office on the way to the next job. The office coordinator then writes the visit report for the client’s facilities manager from those notes, looks up the equipment in the site’s register, works out which parts to order and proposes a return visit.

The report is what the facilities manager files and acts on, so it has to be complete and accurate. When the coordinator is busy, reports leave late, details are missing and the technician is called back to explain what they meant. The work comes back every day in the same shape and there is a clear way to tell whether a report is right, which is where a first workflow usually starts, as we explain in handing a repetitive task to AI while keeping a person’s approval.

What we wrote down before building

Nothing is built before the workflow is written down. We map it with the people who do the work today, on a recorded call with everyone’s agreement: the goal, each step, the tools and data it touches, the exceptions and the result expected. We collect reports the coordinator considers good, check the technical points and agree the scope before the build starts.

Workflow spec for visit reportsAgreed before the build

Visit reports from the technician’s voice note

The page the AI is checked against

Goal

A complete visit report the facilities manager can act on, sent the day of the visit

Starts when

The technician records a voice note at the end of a visit

Reads

The job, the site’s equipment register, the parts list and past reports for the site

Prepares

The report in the company’s format, and the parts request for the office

A person approves

The office coordinator, every report, before it is sent

Never

Sends anything to a client without approval. Promises a return date before the part is confirmed. Names a part that is not in the parts list.

Stops and asks

A part it cannot identify, equipment missing from the register, a voice note it cannot understand

Straight to the supervisor

Anything that could hurt someone, before the report leaves

Level of autonomy

Semi-automated: the AI prepares, a person approves

Kept by the coordinator and the owner. Each recurring edit becomes a line of this page.

Our illustration of a workflow spec for the demonstration. The rules of a real workflow come from the people who do the work.

That page is short, and the AI is checked against it at every step. It says what starts the workflow, what the AI may read and prepare, and what it must never do, such as sending a report to a client without a person or promising a return date before the part is confirmed. It also says when the AI stops and asks, because a workflow that guesses when it is unsure is the one that loses a client’s trust.

How much the AI does on its own is decided in the same document. It can work as a copilot, helping the coordinator write; it can be semi-automated, preparing everything for a person to approve; or it can act alone within written limits and send every uncertain case to a person. We do not force that third level where the variables, the access it would need or the judgement involved would make it irresponsible. In this demonstration every report is approved by a person before it leaves.

What happens after each visit

At the end of a visit the technician records a voice note on their phone, in their own words. The AI matches it to the job, reads the site’s equipment register and the parts list, and writes the report in the company’s format, line by line, keeping the source of each line beside it, as in the illustration at the top of this page.

Where something does not fit, it leaves the gap visible. A part described as “the usual one” is not in the parts list, so the line is held and the technician gets one question; a loose handrail could hurt someone, so it goes to the supervisor before the report leaves. The coordinator receives a draft that is complete except for what needs a person, with the reason written next to each held line.

Once the coordinator approves, the report goes to the facilities manager under the company’s name, the parts request is raised for the office and the return visit is proposed once the part is confirmed. Turning what was said into actions follows the same logic as turning meetings into actions with AI, and drafting a message with the right context is covered in using AI to answer customer emails.

Tested on past visits before it went live

Before the workflow touched a live job, we replayed past visits whose reports were known to be right and compared what the AI produced with what had been sent at the time. Testing on real past cases is how a workflow is delivered against its spec, and it is where most of the useful rules come from.

Our illustration of a test log for the demonstration. A real test uses the business’s own past cases.

Three of the replays failed in the demonstration. The AI chose a part from habit when the technician used a nickname, it repeated a return date the technician had only guessed, and it listed a loose handrail with the minor findings. Each failure became a line in the spec, and the visit was replayed until the report matched. These are the mistakes a business meets when AI is given a task without the rules the team applies without thinking about them, and testing is where they surface before a client sees them.

Where a person approves and what they see

The coordinator does not rewrite the report. They read the draft next to the voice note and the job, with the held lines at the top, and choose to approve and send it, edit it or hold it. Approving a complete draft takes the time of reading it, which is the point of preparing it.

Every edit is kept, because an edit shows something the spec does not say yet. If the coordinator shortens the description of the work in most reports, the expected length belongs in the spec, and the next drafts follow it. The AI works with the access it is given, here read access to the jobs and the register and the right to prepare a draft and a parts request, as we explain in adopting AI securely.

What the owner checks each week

The owner does not read every report. Once a week a short summary arrives: what was sent, what was held and why, what went to the supervisor and which edits the coordinator made most often, with a proposed line for the spec when the same edit keeps coming back.

This week’s visit reportsTo the owner, every Monday

• Sent after approvalMost of them without changes, with a link to each report
• Held, waiting on a technicianA part described by habit, at an office building in Adelaide
• Sent to the supervisor firstA loose handrail, fixed the next day
• The edit the coordinator made most oftenThe description of the work was too long
• Proposed line for the specDescribe the work done in two sentences at most

Our illustration of a weekly summary for the demonstration.

Results are measured with the business’s own figures, such as the time between a visit and the report reaching the client. We show them once they are measured, and a demonstration like this one has none to show. What the summary gives the owner from the first week is a view of what happens on site without anyone having to ask.

What the business owns at the end

Everything we build belongs to the business, and the documentation and the access are handed over as the work goes, so the workflow does not depend on us to keep running. The spec stays the reference: when the business changes the way it works, the spec changes first and the workflow follows.

Tools change too. Each build carries a one-year guarantee from its accepted delivery: defects in our work against the agreed scope are fixed, and if a tool the workflow relies on changes or closes without the business changing anything, a simple adaptation or the connection to an available alternative is included. Small changes the business asks for, such as adding a technician or a new email address, are maintenance. Where the knowledge a workflow reads should live is covered in answers your team can find without asking you.

How we start

When we set up AI around a business, we organise the business knowledge your AI needs, set up the working environment for you and your team with permissions that reflect each person’s role and clear points for human approval, and build the automations with your team, testing them against your actual processes. A workflow like the one on this page is captured, written down, built, tested and delivered against its spec.

The first step with us is a free AI pre-audit: 45 minutes on a call where we look at how you and your team use AI today and which work to hand over first. Bring one task your team repeats every week. You leave with a clear next step, with or without us. See how we help, who we are and how we handle security. For builders and fit-out businesses, we also list twenty-one AI use cases for construction.