Key takeaways
- Start with ‘when this happens in A, then that should happen in B’.
- Exceptions, volume and the plan you are on change the price and the plan more than anything else.
- Name the person who can approve access, and ask them early.
- Use the template. Ten minutes of detail can save days of back-and-forth.
- Never include passwords or API keys in a brief.
‘Connect our CRM to our billing tool’ is a wish, not a brief. It could mean a thirty-minute build or a six-week project, and the difference lives in details that only you know. Writing those details down before you ask for a quote is the cheapest thing you can do to get a fair price and a build that works the first time.
This guide walks through the eleven things a good automation brief contains, with a plain example of each and the reason we ask.
Start with the outcome, not the tools
Complete this sentence: ‘When ___ happens in ___, then ___ should happen in ___.’ If you can fill it in, you have the heart of the brief. If you cannot, spend ten minutes on it, because every other detail hangs from it.
The eleven parts
| Part | What to write | Why it matters |
|---|---|---|
| 1. Goal | The ‘when this, then that’ sentence. | Defines success. |
| 2. Tools and plans | Main platform and its plan or edition. | Plans decide API access and limits. |
| 3. Trigger | What starts it: a payment, a form, a new record, a schedule. | Triggers decide the architecture. |
| 4. Steps | What happens, in order. | Becomes the build plan. |
| 5. Data | Which fields move from where to where. | Mapping is most of the work. |
| 6. Exceptions | Duplicates, empty fields, refunds, failures. | Where automations usually break. |
| 7. Scale | Events per month and your busiest day. | Drives resilience and testing. |
| 8. Sensitive data | Payment, health, HR or children’s data. | Adds safeguards. |
| 9. Timing | Start date and any go-live date. | Sets the schedule. |
| 10. Access | Who can approve access to each tool. | Starts the delivery clock. |
| 11. Done looks like | How you will know it works. | Sets the test plan. |
Exceptions deserve the most space
The normal route is easy to describe and easy to build. The cost is in the exceptions: what happens when a customer already exists, a field is empty, a payment is refunded, an order is edited after it was sent, or the destination system is down. Write one line for each you can think of, and ‘not sure’ for those you cannot. Not sure is useful, because it tells us where to ask questions.
Say how often, and how much
‘A few orders a day’ and ‘up to 800 orders on a sale day’ call for different designs. Volume, and especially the peak, decides whether we need queuing, how we handle rate limits, and how much testing is wise. A single number is enough: events per month, and the largest day you can remember.
Name who can say yes
Delay often comes from permissions. The person who wants the automation is rarely the person who can approve access to the billing tool. Name that person in the brief, and ask them early. Our delivery clock starts when payment, a complete brief and access are all in place, so each of these you settle in advance moves the date forward.
A brief you can copy
We keep a ready-to-fill template on the project brief page. It covers all eleven parts and takes about ten minutes. Attach it to the quote form or send it on the secure upload page.
Common mistakes
- Describing the tool instead of the result. ‘Use the Stripe webhook’ is a method. The goal is ‘mark the order paid’.
- Leaving out the plan. The same platform behaves differently on different plans.
- Forgetting the unhappy path. Refunds, cancellations and edits.
- Skipping the owner of access. Nobody can grant permission they do not hold.
- Sending credentials. Never put passwords or keys in a brief. We show you how to share access safely.
- The goal fits in one sentence
- Plan and API access noted
- Trigger named precisely
- Fields listed with source and destination
- Three exceptions described
- Monthly volume and peak stated
- Sensitive data flagged
- Access owner named