How it works

A twenty minute conversation about one recurring job: the work a business role carries today, whether that currently sits with a founder, an operations lead or a team.

What we need from you

A description of the work: what starts it, who owns the result, which tools carry it, roughly how often it happens, and where it currently stalls.

What you leave with

Either a view on fit or a specific list of what is missing before that view can be formed. A no is a real outcome here. Some work is too varied, too rare, or too dependent on a relationship to hand over, and that is cheaper to find out in a short call than in a build.

An assessment is optional depending on the engagement. If one is proposed, it can trace the real process, identify exceptions and produce a written definition of done.

Its scope and terms are agreed with you. Ask what the output contains before you agree to it. Every engagement still needs an agreed written scope at stage three, whether or not an assessment runs.

What you leave with, if it runs

A written description of the workflow: the trigger, the records involved, which actions need approval, the known exceptions, and the cases the finished system has to handle correctly.

Whichever route gets you here, the build does not start until a document says what the worker is responsible for and what falls outside it.

What we need from you

Confirmation that the description matches reality, including the exceptions your team handles without thinking about them. This is the stage where undocumented knowledge has to come out of people's heads.

What you leave with

An agreed scope that names the role, the systems it touches, the actions that wait for approval, and what counts as new work later.

What we need from you

Accounts and permissions in the systems the worker uses, a decision about how wide those permissions go, and a named person who can answer questions during the build.

What you leave with

A connection check for every system, showing a real read, a scoped write where one is permitted, and a readback confirming the system saw what it wrote.

The worker runs on real items while a person checks the output before it goes anywhere.

What we need from you

Time from your named owner to look at the results and say what is wrong. This is the stage that decides quality, so it is worth resourcing deliberately rather than fitting around other work.

What you leave with

A record of real items processed, the corrections made, and the exceptions that nobody had written down before.

Acceptance is measured against the cases agreed in the scope rather than against a demo.

What we need from you

A decision from the named owner that the system handles the agreed cases correctly, and a decision about which specific actions may run without waiting for approval.

What you leave with

A launched system with a named owner on each side, and a written boundary listing what runs on its own. Consequential actions stay on approval. Widening the permitted list is a separate decision each time.

Whether a system passes is decided by the agreed cases, which is why those cases are written down before the build rather than argued about afterwards.

After launch, we watch for errors, renew credentials, handle a connected tool changing how it works, and extend the worker when the agreed work changes. Items the system is unsure about go to a person, the fix is logged, and the rules are tuned so the same miss does not keep coming back. Autonomous work stays inside the permitted boundary from stage six, and authority is widened one action type at a time, in writing, after it has held on real items.

Your team keeps policy, approvals, exceptions, source truth, and the decision about how much the worker may do on its own.