CRM Automation Requirements Template

An automation requirement describes what a workflow must do in plain language, precisely enough that someone else could build it and someone else again could test it. This template covers the fields that tend to get skipped (exclusions, re-entry, what happens when data is missing) and ends with a fully worked example for a demo-request workflow.

How to use this template

Write one requirement per automation, before building. If the requirement is hard to fill in, that’s useful: it means the business rule isn’t settled yet, and building now would only bake in the ambiguity.

Write in business language first. “When a lead requests a demo” is better than “When form ID 4471 is submitted”, because forms change. Add the technical detail (property names, list or segment names, form IDs) in the implementation notes section.

A requirement is finished when the acceptance criteria could be handed to a tester who has never seen the conversation. The workflow QA checklist is designed to be run against them.

Part 1: Summary

Automation name: using your naming convention.
Requested by: name and team.
Business owner: who decides how it should behave once live.
Problem it solves: one or two sentences describing what goes wrong today without it.
Lifecycle stage(s) affected: link to your lifecycle map.
Platform: where it will run, and any other systems involved.
Priority and target date.

Part 2: Trigger

Trigger event or condition: what starts it, in business terms.
Data source: which system produces that event or value, and how it reaches the CRM (native form, integration, API, import).
Object enrolled: contact, company, deal, profile, order, ticket.
Expected volume: rough number of enrollments per day or week.
Existing records: whether records that already meet the trigger when the automation goes live should enroll.

Part 3: Conditions

Entry conditions: anything that must also be true for a record to enroll (country, consent, record type, property value).
Branch conditions: each decision point, the rule for each path, and the default path.
Missing data rule: what happens if a property a condition depends on is blank.

Part 4: Exclusions

Never enroll: groups that must never enter (existing customers, open deals, unsubscribed, employees, test records, competitors).
Remove if: conditions that should take a record out once enrolled (for example a deal is created, an order is placed, they reply).
Conflicting automations: other automations the same record could be in at the same time, and how the conflict is resolved.

Part 5: Timing

Start: immediately, after a delay, or at a specific time.
Delays: each wait, with unit and reason.
Time windows: business hours, time zone used, days to avoid.
Waits for an event: what the automation waits for, the maximum wait, and the timeout path.
Total duration: from enrollment to final step.

Part 6: Actions

List each action in order, one line each.

Step number and type: send email, send SMS, update property, assign owner, create task, create deal, notify user, add to list or segment, call webhook, branch, delay.
Details: content reference, property and exact value, recipient, due date.
Failure handling: what should happen if the action fails (retry, notify owner, log).

Part 7: Re-entry

Can a record enter more than once? Never, once per qualifying event, or after a cooldown.
Cooldown: minimum time between enrollments, if any.
What resets: if re-entry is allowed, which properties or counters the automation should reset or not touch.

Part 8: Expected outcome and measurement

Expected outcome: what should be true for a record after it completes (owner assigned, stage changed, meeting booked, order placed).
Success measure: the number you’ll check, and where.
Review date: when you’ll look at the results and decide whether to change it.

Part 9: Acceptance criteria

Write each as a testable statement: given a starting situation, when something happens, then a specific result. Include at least one negative case (something that must not happen) and one edge case with missing or unusual data.

Part 10: Implementation notes

Properties used and updated: internal names.
Lists, segments, forms, templates referenced: names or IDs.
Dependencies: integrations, fields or other automations that must exist first.
Open questions: anything still undecided, with an owner.

Worked example: demo request follow-up

Summary. Name: “Lead | Demo request | Route + follow up”. Requested by the sales manager. Business owner: head of sales. Problem: demo requests submitted after 3pm on Fridays sit untouched until Monday, and some go to reps who have left. Lifecycle stage affected: Lead to Sales Qualified Lead. Platform: HubSpot, with calendar booking through the meetings tool.

Trigger. A contact submits the “Request a demo” form on any page. Expected volume: 25 to 40 a week. Existing records: none should enroll at launch.

Conditions. Contacts with a business email domain go to routing. Contacts with a free-mail domain (gmail.com, outlook.com and similar) go to an SDR review queue instead. If country is blank, route to the default region (North America) and flag the record with lead status “Needs review”.

Exclusions. Never enroll contacts whose company has an open deal in the New Business pipeline; instead notify the deal owner. Never enroll lifecycle stage Customer; instead create a task for the account manager. Remove from the workflow if a meeting is booked or a deal is created. Conflicting automation: the “Content download nurture” workflow; this workflow unenrolls contacts from it on entry.

Timing. Routing and notification happen immediately. Follow-up email 1 sends immediately. If no meeting is booked after 1 business day, the rep gets a reminder task. If no meeting after 3 business days, follow-up email 2 sends between 9am and 5pm in the contact’s time zone. Total duration: 5 business days.

Actions.

Set lifecycle stage to Lead (only if currently Subscriber or blank).
Set lead status to “New”.
Assign contact owner by territory rules (see the lead routing workbook); fallback owner is the SDR manager.
Send internal email to the owner with the form answers and record link.
Create task “Call demo request” for the owner, due in 2 business hours.
Send follow-up email 1 from the owner with their meeting link.
Delay until a meeting is booked, maximum 1 business day.
If no meeting: create reminder task. Delay until meeting booked, maximum 2 more business days.
If still no meeting: send follow-up email 2. Set lead status to “Attempting to contact”.

Re-entry. Allowed once per form submission, with a 30-day cooldown. A repeat request within 30 days notifies the existing owner instead.

Expected outcome. Every demo request has an owner within 5 minutes and a first call attempt within 2 business hours. Success measure: median time from submission to first logged call, and share of requests with a meeting booked within 5 business days. Review after 6 weeks.

Acceptance criteria.

Given a new contact in Germany with a business email, when they submit the demo form, then they are assigned to the EMEA SDR queue owner and the owner receives a notification within 5 minutes.
Given a contact whose company has an open New Business deal, when they submit the demo form, then they are not enrolled, no follow-up email is sent, and the deal owner receives a notification.
Given a contact with a gmail.com address, when they submit the form, then they are placed in the SDR review queue and no follow-up email sends automatically.
Given a contact with no country value, when they submit the form, then they are routed to North America and lead status is “Needs review”.
Given an enrolled contact who books a meeting after email 1, then no reminder task is created and email 2 never sends.
Given a contact who submitted the form 10 days ago, when they submit it again, then they do not re-enroll and their current owner is notified.
Given a contact with lifecycle stage Customer, when they submit the form, then lifecycle stage is not changed.

Open questions. Should partner-referred demo requests skip routing and go to the partner manager? Owner: head of sales, due before build.