Your automation brief, in six decisions
- Trigger: the event that starts the work, with one real example.
- Finish line: the record, response or handoff that counts as complete.
- Owner: who handles the usual path and who reviews exceptions.
- Systems: where information starts, where it goes and who can access it.
- Boundaries: what runs by a rule, what AI may suggest and what needs approval.
- Baseline: time, corrections and running costs to compare during the pilot.
Bring a real example to the table
“Automate our operations” is too broad to estimate. Start with a task that happened recently: a customer enquiry, an invoice query or a support request. Ask the people who handled it to walk through the actual sequence, including messages, copied fields and moments where they had to wait.
Write down the trigger and the finish line. An enquiry is not complete just because someone received an email. It may need an owner, a response and a recorded next step. If the team disagrees about when work is finished, resolve that definition before choosing tools.
Separate the usual path from the exceptions
Map the common sequence first. Then collect the exceptions: missing information, duplicate submissions, an unavailable approver, an attachment that cannot be read. These cases belong in the scope because they determine how much work returns to a person.
For each exception, choose an owner and a visible state. “Needs review” with a reason is more useful than an automation that quietly stops. A person should be able to see what happened, correct the input and resume the task without reconstructing it from scratch.
Decide what can act automatically
Copying a validated field and proposing a response are different actions. The first may follow a fixed rule; the second may involve interpretation. Put decisions into three groups: deterministic rules, suggestions that require review, and actions that need explicit approval.
AI is useful when the task involves language or variable inputs. It does not remove the need for permissions, validation and a dependable record of changes. Keep those controls in the application around the model.
Write a brief that can be tested
Your first brief should name the trigger, systems involved, required fields, decision rules, exception queue and process owner. Add a few representative inputs and the expected result for each. Include an example that should fail safely.
Measure the current task before the pilot starts. Count the time spent checking results as part of the automated process. This makes the final decision more honest: the business is buying a better way to complete work, including its review and maintenance.
Leave with a bounded first release
Finish the audit by choosing one path to build and a clear point to stop. A small release might capture a website enquiry, match a contact and route it to a named owner. Keep the next improvement in a separate backlog. The first release should be understandable enough that the team can explain what happens when it succeeds and when it fails.