How to define an automation before building it

Pick a recurring problem your team recognises

A useful starting point is a repeated delay, manual transfer or check. For example, the team copies form enquiries into CRM and then posts a message asking who will follow up. “Automate our sales” is too broad to estimate or test; “record this form once and assign the right manager” is a defined first workflow.

Bring a recent example with sensitive information removed. Explain how it starts, what people do today and what a successful ending looks like. Describe the work before choosing AI, a workflow platform or a new CRM.

Name the trigger and source of truth

Specify which event starts work and how you recognise it uniquely. A submitted form, approved document and CRM stage change are different triggers. Explain whether repeats, corrections and cancellations are possible.

Choose the authoritative record for each important field. If a price appears in both a spreadsheet and CRM, decide which one wins. An integration should not quietly invent a reconciliation rule that the business never approved.

List required information and actions

Separate data required to begin from information that can be collected later. Map each input to the result it supports. If a field is missing or contradictory, define a visible exception rather than allowing the system to guess.

• Event identifier and source.
• Required customer or document fields.
• Lookup rules and authorised data sources.
• The record, task or draft to create.
• The person responsible for the next step.

Draw the human approval boundary

Rules can handle repeatable decisions. AI can help interpret a message or extract information from an approved document. Neither should automatically gain authority to pay, sign a contract or make an unusual customer promise.

Write down which actions are automatic, which prepare a draft and which require approval. A rejected or expired approval also needs a next step. Permissions and recovery should be designed with the workflow, not added only after launch.

Agree acceptance scenarios before estimating

A normal scenario is necessary but not sufficient. Include missing information, a duplicate event, an unavailable provider and a request for a person. State the expected record, notification and recovery behaviour for each scenario.

The First Line AI product is an example of this approach: the work includes first response, approved qualification and handoff. The sales claim is not simply “a bot answers”. Scope also needs access, knowledge, external provider costs and support boundaries.

Measure one change without inventing ROI

Choose an operational measure you can observe before and after: repeated entries per request, completeness of the record, time until assignment or manual work per batch. Write down the sample and measurement period. Avoid presenting a projection as a measured result.

For a rough planning estimate, multiply repeated tasks by observed manual minutes and compare that time with the work that will actually disappear. Review the estimate after launch. The first version should remove a clear bottleneck; a bigger system can wait until that improvement is demonstrated.