What information we need to automate a process

Start with one process, not the whole business

Define where the work starts and when it ends. ‘Automate management’ is too broad. ‘Record a request received by phone, assign it and update its status’ identifies a specific workflow.

Note what triggers the process, what the outcome should be and who confirms that the work is complete. If you have several candidates, explain where manual tasks repeat most often or where errors occur; we can then assess where to start.

Explain how the work happens today

You do not need a professional diagram. An ordered list can show the steps, waiting periods and changes between tools.

• What triggers the process: a call, a request, a payment or a status change.
• Which steps happen, in what order and who is involved.
• Which information is copied and where it is stored.
• Where delays, corrections or uncertainty build up.
• How often the process runs and whether there are busier periods.

Identify the tools and data

To assess an integration, we need to know which systems are involved. The process might concern calls, advertising tasks, service coordination or payments. The fact that two tools exist does not guarantee that they can connect in the way you need.

Share anonymised examples. We do not need passwords, API keys or administrator access for this first enquiry. If permissions are needed later, we will agree on the channel and level of access.

Describe what happens when something goes wrong

The normal workflow is only part of the design. What happens if information is missing, a request is duplicated, a provider fails, a payment is declined or an assignment changes?

For each exception, decide who should be notified, which information they need and whether the process should stop, retry or move to human review. Some decisions should retain manual approval. We also need to know how to return to the previous workflow if a test fails.

Agree on how to assess improvement

Before development, define what a better process would look like. These criteria can be a starting point:

• Time spent on manual tasks and how it will be recorded.
• Requests that need correction and what counts as an error.
• Information that still needs to be copied between tools.
• Outstanding incidents and the time needed to resolve them.
• Steps that require intervention and the circumstances involved.

If you do not have records yet, do not invent figures. We can define what to observe before starting and compare equivalent situations afterwards. These are project evaluation criteria, not promised results.

Example: from a request to confirmation

A hypothetical example to prepare for the conversation, not a client project or an achieved result.

1. Receive

   A phone call creates a request.

2. Validate

   The information and possible duplicates are checked.

3. Coordinate

   The service is assigned using the agreed rules.

4. Resolve

   The payment status is checked before confirmation or a notification to a person.

The important questions are who reviews an incomplete request, what happens if the service changes and who handles a declined payment. The final scope depends on the available tools and the rules we agree on.

Checklist for the first conversation

• I have identified one process and its expected outcome.
• I can explain the current steps and who is involved.
• I have a list of the tools and data involved.
• I have identified repetitive tasks, errors and important exceptions.
• I know who can authorise access and integrations.
• I have noted priorities, constraints and necessary dates.
• I have prepared examples without personal data or credentials.
• I have considered what could be measured before and afterwards.

It is fine if some answers are missing. Tell us what you know and what we need to review together; you do not need a complete technical specification to get in touch.

A completed brief to help you prepare your own

Copy this template into your working document and replace the information with your own process. You can also print this guide from your browser.

Fictional educational brief. It does not describe a client or achieved results.