An automation project brief should explain what starts the process, what useful result it should produce, and who owns the work when something goes wrong. One clear page is enough to begin a productive scoping conversation.
You do not need to choose a model or integration platform first. Start by describing the work your team already performs and the part that causes repeated friction.
Describe the current process
Write the steps in the order they happen. For example: a website inquiry arrives, someone copies details into the CRM, a manager assigns an owner, and the owner replies. Mark where work is delayed or repeated.
Use a real process, but sanitize examples before sharing them. Leave out passwords, tokens, and unnecessary customer details. A builder needs to understand the task, not receive unrestricted access during the first conversation.
Name the starting event and desired result
Be precise about the trigger. “A valid website form is accepted” is clearer than “a lead happens.” Then describe the output: one record, an assigned owner, and a reply draft awaiting review.
Our article on why website leads get lost can help identify the handoff worth fixing. The guide to turning visits into customer inquiries adds context for the customer’s next step.
List the tools and permissions
Name the systems involved and whether the required integration is already available. State what the automation may read, change, or send. Keep actions that require approval in a separate list.
If the proposed system uses AI, NIST’s AI RMF Playbook is a useful reference for risk-management thinking. In the brief, turn that into specific boundaries: what must be reviewed, what must be held, and who can authorize an exception.
Include the awkward cases
Add a few examples that could break a simple demonstration:
- The required contact field is missing.
- The same event arrives twice.
- The message belongs to an existing customer rather than a new lead.
- A connected tool is unavailable.
- The request falls outside the business’s supported services.
Write the expected response to each. “Send to a review queue owned by the office manager” is more useful than “handle errors gracefully.”
Define a small acceptance check
Say how you will know the first version works. For a lead workflow, that might mean the agreed test cases create the correct records and owners without repeated messages, and failures remain visible for manual handling.
Avoid using a revenue target as the only acceptance condition for a technical build. Revenue depends on factors outside the automation. Separate reliable workflow behavior from the commercial outcome you hope it will support.
Finish with ownership and scope
Name the person who will use the system, the person who can approve changes, and the maintenance responsibilities that need discussion. List what is excluded from the first version so the project has a clear boundary.
Automation brief FAQ
Do you need to choose the software first?
Usually, define the process first and list the tools you already use. A builder can then check whether those tools support the required inputs and actions. Choosing software before defining the job can leave you adapting the business process to a feature you did not need.
How many examples should the brief include?
Include enough to show an ordinary case and the main exceptions. For an inquiry process, a complete request, missing information, and a repeated submission are useful starting points. Label the expected result for each example. A small, clear set is more useful than a large folder with no explanation of what should happen.
What belongs outside the first version?
List actions that require a different approval, additional data, or a separate integration. For example, sorting inquiries does not automatically include sending quotes or changing billing records. Put these exclusions in the brief so both sides can discuss later additions without treating them as part of the original acceptance test.
Hassan Labs can use this brief to assess a practical first build around your tools. Bring the one-page process description, sanitized examples, and acceptance checks. Those materials make it easier to compare proposals and avoid buying a system whose job nobody has defined.