What a system brief is not
A system brief is not a feature list. It is not a wish list of automation capabilities. It is not a requirements document with fifty line items.
A system brief is a single-page document that answers five questions. Any developer, any automation platform, any contractor you hand it to should be able to read it in five minutes and understand exactly what needs to be built and how you will know it is working.
If it takes longer than a page, you are scoping a project, not a system. Break it down.
The five questions a brief must answer
1. What triggers this system? Describe the specific event or condition that starts the workflow. Be as precise as possible: 'a new row is added to the CRM with lead status = qualified' is better than 'a new lead comes in.'
2. What is the intended outcome? One sentence. What should be true after the system runs that was not true before? 'The lead receives a personalized follow-up sequence within 5 minutes and is routed to the appropriate sales rep.'
3. What data does it need? List every field or data source the system needs to make its decisions. If the system needs to know lead source, company size, and last activity date — list all three. Missing data kills logic.
4. What are the decision rules? Describe how the system should branch. If lead score > 80, route to senior rep. If lead score < 40, add to nurture sequence. Write these as plain-language conditionals before thinking about implementation.
5. How will you measure success? Define a metric and a target. Not 'better follow-up' — '90% of qualified leads contacted within 15 minutes, measured weekly in the CRM report.'
What to do with the brief
A completed brief serves three functions: it aligns everyone on what is being built before the build starts, it gives the builder clear acceptance criteria, and it gives you a baseline for measuring ROI after launch.
Share it before scoping. If your implementation partner, developer, or automation tool does not understand the brief, the scope is not clear enough yet. Confusion before the build is infinitely cheaper than confusion during it.
Revisit the brief when requirements change. A brief that changes frequently means the underlying problem is not yet well understood. Pause and clarify before resuming the build.