Notes from running AI-assisted work in actual small businesses.

Field note   2026-05-08 · 4 min read

What we tell mid-size practices when the CEO asks: have we looked at AI?

The question usually lands on an Operations Manager, Practice Manager, Business Manager, or outsourced IT partner. It sounds strategic. In practice, it often means three staff are already using AI tools, two vendors are emailing the CEO, and nobody knows what data has gone where.

The wrong answer is a tool demo. The right answer is an operating pass.

The first response we recommend

1. List what is already happening. Staff use, paid subscriptions, browser extensions, meeting tools, CRM features, and anything billed in USD. Shadow AI is still AI.
2. Write the data boundary. What can go into AI tools, what cannot, and which tools are approved. Keep it short enough that staff might actually read it.
3. Pick one workflow people already complain about. Intake, onboarding, quote follow-up, reporting, inbox triage, or policy retrieval. Keep the scope narrow enough to inspect and improve.
4. Name the owner. If nobody owns the workflow, AI will not fix it. It will just make the ambiguity faster.
5. Design the assist point. Draft, summarise, classify, route, retrieve, or alert. Start where a human can review the output before it touches a customer or decision.
6. Write the off-switch before launch. Who can pause it, what triggers a pause, and how the team keeps working without it.

A 30 to 80 person practice does not need AI theatre. It needs enough governance to stop drift, enough process clarity to choose the right pilot, and enough documentation that the system can outlive the person who built it.

If the CEO wants a sentence: "Yes, we have looked at AI. The first useful move is not a chatbot. It is a controlled workflow pilot with data rules, a named owner, human review, and an off-switch."

Field note   2026-06-14 · 5 min read

Do not automate work until you know where the freed capacity should go.

A lot of team AI advice still sounds like individual productivity advice with more stakeholders. Give everyone access. Teach prompts. Find use cases. Celebrate time saved.

That is not enough. In an organisation, time saved without a destination becomes politics. Staff hear job shrinkage, more output pressure, or another vague transformation program.

The better first question

Before asking what AI can automate, ask what valuable work is not happening because the team is already overloaded.

• Which customer follow-up is being skipped?
• Which QA, documentation, or training never gets done?
• Which process improvements sit in the "we should really" pile?
• Which senior people are buried in work that should be supported or delegated?
• Which learning loops are sacrificed whenever the week gets busy?

We call this Capacity Destination Mapping: deciding where AI-freed capacity should go before automating the work.

The practical assets are here: Capacity Destination Mapping worksheet and team-lead GPT prompt.

Field note   2026-05-06 · 4 min read

When the vendor changed the model under you, your tone drifted overnight.

A real thing that happened on a quote follow-up pilot. Drafts had been steady for months. Then the vendor rolled out a "minor improvement" to the underlying model. The next day, drafts started signing off with a peppy "Cheers!" instead of the client's house tone. Nothing in the prompt changed. Nothing on our side changed. The model changed.

What we now do on every pilot

1. Pin the model name and version in the configuration. "The latest" is not a control. Where the vendor will not let you pin, document the exposure in the runbook so the owner knows it is a known risk.
2. Keep a small set of golden inputs: five or ten real prompts with the expected output shape. Run them at the start of each review.
3. Sample on a cadence, not on vibes. Twenty drafts a week, scored against the golden set. If two in a row drift, the assistant moves to Watch, not "we will keep an eye on it".
4. Tone is in the kill criteria. Not just error rate. Tone drift counts.

If you only get one thing from this note: the cheapest way to spot drift is a fixed set of golden examples you actually look at. Not a dashboard. A document a person reads.

Field note   2026-04-28 · 3 min read

Stop trying to automate the workflow nobody owns.

A common pattern in service businesses: a workflow is technically "everyone's job", which means it drifts, gets done inconsistently, and breaks every time someone is on leave. The owner thinks AI will fix it. AI will not. AI will reproduce the inconsistency, faster, in a more confident tone.

What actually fixes it: a named human owner. Before any assistant gets involved. The owner does not have to do the work themselves. They have to be accountable for it being done.

Sequence we use

• Name the human owner in writing. Not "the team".
• Map the current process as one page: trigger, steps, decisions, hand-offs, end state.
• Identify the steps that are genuinely repetitive and bounded. Those are the AI candidates.
• Leave the judgment calls and customer-specific decisions with the owner.
• Then, and only then, pilot a bounded assistant with a defined off-switch.

If you cannot name the human owner of a workflow, you do not have a workflow. You have an opinion.

Field note   2026-04-15 · 3 min read

The AUD cost surprise hiding in your AI tool stack.

A small services business in Melbourne ran a quick audit with us last quarter. Five people, six AI tools across the team, all signed up directly with company emails. Most billed in USD. The owner had been quoting their accountant the USD figures.

Once we converted to AUD with current FX, added GST, and picked up two annual plans that auto-renewed at higher tiers than the team needed, the real spend was about 38% higher than the owner thought. None of it was rogue. All of it was unmanaged.

The 30-minute audit we recommend

• List every AI tool the team is paying for, including ones billed to personal cards and reimbursed.
• Convert each to monthly AUD, GST-inclusive, at current FX. Use a fixed FX figure for the audit so the spreadsheet is reproducible.
• Check the renewal date and the tier each is on. Many teams are on a tier above what they use.
• Confirm whether each tool's data tier is the right one for client information, or whether you are on a free or consumer tier with retention enabled.
• Decide which tools are approved, which are deprecated, and which need a tier change.

Operations hygiene, not a heroic project. The savings tend to fund the governance work that should have been done anyway.

Field note   2026-04-02 · 3 min read

Test the off-switch before launch. Every time.

An assistant pilot is not ready for launch until someone has turned it off, end to end, while the team kept working. Sounds obvious. Almost nobody does it.

We have seen pilots where "off" meant disabling the integration, but a stale credential kept it running for an extra eleven hours. We have seen pilots where the queue backed up because nobody had the manual fallback documented. We have seen pilots where the off-switch worked, but the owner did not know who had the authority to flip it.

The off-switch test

1. The named owner triggers the documented off-switch in front of a witness.
2. We watch the system for the time it takes to drain in-flight work.
3. The team performs the manual fallback for the same workflow for at least one full work cycle (a day, a shift, a batch).
4. We re-enable the assistant and reconcile what happened during the off-period.
5. We write the result into the runbook with a date and a witness name.

If the off-switch test is too disruptive to run, the assistant is not ready to be turned on.