2026-10-07 / Spreadle

How to brief a business automation project before writing code

Define triggers, records, responsibilities, exceptions and human handoffs before automating enquiries, appointments or internal tasks.

An automation brief should describe the work well enough that someone can perform it manually. If the team cannot agree what happens next, software will repeat the uncertainty faster. Begin with one workflow and its exceptions.

Name the trigger and the finish

What starts the process: an enquiry, a confirmed payment, a scheduled time or a staff action? What does completion mean: a recorded appointment, an assigned task, a notification or an approved update?

Write a sample case from start to finish using fictional data. List the records created and the person responsible at each step. Include the systems involved without copying private customer information into the brief.

Decide where the authoritative record lives

A conversation, a spreadsheet and an operations dashboard can each show a different version of the same task. Choose which system owns the record and how updates reach the others. Define what happens when one system is temporarily unavailable.

For appointment work, viewing a time and successfully reserving it are different events. The system needs rules for competing requests and a clear confirmation state. Specify those rules before designing a cheerful confirmation screen.

Write the exceptions beside the happy path

  • The customer provides incomplete or inconsistent information.
  • An external service times out or sends a repeated event.
  • A staff member changes a record while the automation runs.
  • The customer asks to cancel or alter the task.
  • The request needs a decision the automation cannot make.

For each case, say whether to retry, stop, request clarification or hand the task to a person. Identify the information the person needs to continue without asking the customer to repeat everything.

Keep the human handoff visible

An assistant should have a clear route to staff when the conversation needs judgment. Define opening hours or response expectations only when the business can support them. Avoid language that implies a human is present when the route only records a request.

Our Smile Stories WhatsApp assistant case study includes an interactive sample of booking changes and reception handoff. The demo uses sample data and does not contact the clinic. It is useful for inspecting a journey before connecting live systems.

Agree on a reviewable first release

Choose a small set of workflows, sample cases and failure checks. Decide who approves the behaviour and what records or logs the operator will inspect. Include access, maintenance and rollback responsibilities in the handover.

Explore our custom software and automation service. If your current process runs in a spreadsheet, read when a custom application is worth considering before committing to the integration work.

Keep planning your project

← Back to the journal

Make a start

What do you have in mind?

Tell us the goal, the current workflow, and your approximate budget.