A useful automation starts with a specific job. “Automate our business” is too broad to price, test or hand over. “Collect the documents for this client and flag what is missing” gives everyone something concrete to work with.
Describe the work as it happens.
In a first conversation, we ask what starts the process, which tools are involved and what someone does next. A recent example is more useful than an idealised process chart. We want to see the missing field, the duplicate record and the message that needed a judgement call.
For client intake, the starting point might be an uploaded document. The finish could be a checklist ready for a member of staff to review. Those boundaries define the initial workflow.
Separate rules from judgement.
Copying an agreed field between systems is a different job from deciding whether a document is acceptable. We identify the repeatable rules and make the review points explicit. If AI is useful for reading or classifying information, its output still needs an agreed way to handle uncertainty.
Write down what “working” means.
We agree acceptance checks before implementation. Can the same file arrive twice without creating duplicate work? Does an incomplete record reach the right person? Can the team see what happened when a connection fails? Can an authorised member of staff pause the process?
When this happens: ___.
Our team currently does: ___.
It uses these tools: ___.
The result we need is: ___.
A person must approve: ___.
Keep the first scope visible.
Our standard accounting offer has a defined scope. An extra integration or approval rule is discussed and quoted separately. A different workflow may need bespoke discovery. That distinction helps both teams understand what is included before the build begins.
You do not need to arrive with a technical specification. Bring one recurring task and an example of how it works today.