Direct answer
A brief prevents the quote from being a guess. Without one, every vendor fills the gaps with their own assumptions and the prices cannot be compared. A useful automation brief is short and specific: it states the process and its trigger, lists the systems and who can grant access, gives realistic volumes, describes what goes wrong today, defines how you will judge success, names constraints, and attaches examples. Write it as if for someone who has never seen your business. Use the sections below as headings and answer each in a few lines. If you cannot answer one, write 'unknown' rather than skipping it; an honest unknown is useful to a builder. For phases and pace see the workflow automation project timeline, and to check which process to automate first use the Automation Opportunity Finder.
1. Process and trigger
Name one process. Then write the following:
- What starts it: a form submission, a status change, an email, a schedule, or a person's decision
- The steps in order, and who or what does each step today
- What the finished state looks like and where the result must end up
- Which steps need a human decision and which are mechanical
- Who owns the process and can answer questions about it
2. Systems and access
List every tool the process touches, including the humble ones such as shared inboxes and spreadsheets.
- Name, purpose and plan or edition of each system, if you know it
- Who administers it and can create a dedicated account or credential for an integration
- Whether you have a test environment, a sandbox or only live data
- Anything you know about limits: restricted integration access, approval steps or a vendor who must be contacted
- Whether any system is due to be replaced soon, since that changes what is worth building
Do not assume connectors exist
It is safer to write 'we would like system A to talk to system B' than 'use the connector', because a vendor cannot promise a ready-made connection without checking what each system exposes. A good brief leaves that question open and lets the builder confirm it.
3. Volumes
Volume affects design, cost of running and the limits you may hit. Give your own figures, from your own records, in rough terms:
- How many times the process runs in a typical period, and how much that varies
- Busy periods or spikes and what causes them
- Records or files per run, and their approximate size
- Expected growth, if any, over the next year
- How quickly each run must complete, if speed matters at all
4. Exceptions
The exceptions are usually the difference between a demo and a working system. Write down what goes wrong today:
- Missing or badly formatted information in incoming records
- Duplicates and repeated submissions
- Cases that need a manager's approval
- What happens when a system is down or a step fails
- Who should be told when something cannot be processed, and how
- Cases you already know the automation should not handle
5. Success measure
State how you will know it worked, in terms you can check yourself. For example: fewer items waiting for manual entry, a specific manual report no longer prepared by hand, or a named error type no longer appearing. Do not borrow a saving from someone else's case study. Note how you currently measure the process, because a measure needs a starting point, and say who will check and when.
6. Constraints
Constraints narrow the solution and are cheaper to state up front:
- Where data may or may not be stored or processed, and who must approve any change to that
- Accounts and tools that must stay in your name
- Systems that must not be modified
- Budget range or funding limit, if you are willing to share it
- A date something depends on, and what that dependency is
- Your preferred tooling or hosting, if you have a strong preference
- How much of the ongoing running you want to handle yourselves
7. What to attach
Attachments turn descriptions into facts. Include, with sensitive data removed or replaced:
- Three to five real examples of the input, including one awkward one
- A screenshot or export showing each system's relevant screens or fields
- Any existing documents describing the process
- A sample of the expected output
- A list of the people involved and their roles
8. Using the brief to compare quotes
Send the same brief to each vendor and compare what comes back against it, not against each other's marketing. Check that each quote states what is included and what is not, how exceptions are handled, who holds the accounts and credentials, what is handed over at the end, and what it assumes about system access. A quote that ignores your exceptions section or quietly assumes a connector has left the hard part out. Questions from a vendor are a good sign: they show the gaps in your brief are being found now instead of during the build.
Turning the brief into a scope
LATYNEX is a remote English-language vendor. We work from a brief like this to write one scope and one price that we agree in writing before work starts, with accounts and code handed over in your name, and a straight answer if we are not the right fit. A single workflow across a small number of systems can fit the fixed-scope Automation Sprint (€1,690); larger designs are quoted once the process is mapped. There is no discovery fee. See workflow automation and systems integration, and the AI automation agency access requirements for what we will ask for on access.
Questions
How long should the brief be?+
One to three pages is plenty. A brief that is specific about one process is more useful than a long one describing the whole business.
What if I don't know the volumes?+
Write 'unknown' and say where the figure could be found, such as a report, an inbox count or a system export. A rough estimate from your own records is better than none, and a builder can flag where it matters.
Should I include my budget?+
It is optional, but sharing a range lets a vendor propose a scope that fits instead of guessing. If you prefer not to share it, compare quotes on what is included rather than on price alone.
Can I send real customer data as examples?+
Prefer to remove or replace personal details. What matters is the structure and the awkward cases, not the identities. If real data is needed later, agree how it is shared and who can see it first.
What if the brief covers several processes?+
Pick one to be first and note the others as later phases. A first workflow that is small and complete is easier to scope, deliver and judge than a broad programme.