Sales · Free implementation template
AI CRM Requirements Template
Define the records, stages, ownership rules, automations, integrations, and measurements an AI-enabled CRM actually needs before anyone starts building.
Introduction
What the AI CRM Requirements Template is for.
Define the records, stages, ownership rules, automations, integrations, and measurements an AI-enabled CRM actually needs before anyone starts building.
A completed sales template is a specification for CRM behaviour: which records are authoritative, which stage transitions matter, who owns the next action, and what may run without a human. This one covers business outcome, records and stages, automation boundaries, measurement, and it is written for smb sales teams, revops leaders, crm replacement projects. Each section is a decision that has to exist before the workflow can be built or automated — the prompts are there to force the decision, not to be filled in for their own sake.
A completed template is also a structured brief. ARIA can read it as the objective, the systems involved, and the constraints that apply, which is what turns the specification into something that runs rather than something that gets filed.
- Category
- Sales
- Sections
- 4
- Format
- Markdown, no signup
- Best for
- SMB sales teams, RevOps leaders, CRM replacement projects
The problem
Specifications fail on the decisions nobody wrote down.
Sales process documentation usually describes what the team intends to do rather than what the system will enforce. The gap shows up as pipeline that cannot be forecast: stages mean different things to different reps, and the reporting built on top inherits the ambiguity.
The expensive part is not writing the process down. It is that every automation, dashboard, and handoff built afterwards encodes whichever interpretation the implementer happened to hold, and those interpretations only surface when the numbers disagree.
Filling this in first turns the disagreement into a conversation between the people who own the outcome, before it becomes a defect distributed across the CRM.
You're likely here because
- You are choosing or replacing a CRM and want requirements before demos
- Reps maintain private spreadsheets alongside the CRM
- Forecast numbers change depending on who produces them
How it works
From a blank AI CRM Requirements Template to a running workflow.
Each stage is a decision that has to be made once. Making them in this order is what keeps the later ones answerable — you cannot set an automation boundary before you know who owns the record.
Step 01
Fix the stage definitions
Each stage gets an entry condition and an exit condition that can be evaluated from data rather than from judgement. Stages that cannot be evaluated from a record are not stages; they are opinions.
Step 02
Name the record owner
Every record and every exception gets one accountable owner and a named backup. Shared ownership is the most common cause of a stalled pipeline workflow.
Step 03
Set the automation boundary
Mark which actions may run automatically, which require approval, and the numeric thresholds that separate them. "Significant deals need review" is not a rule a runtime can apply.
Step 04
Declare field authority
Where the CRM and another system both hold a field, record which one wins. This is what keeps an automated enrichment from overwriting an amount or a close date.
Step 05
Attach the measurement
Each metric names the population it is computed over, so conversion and cycle time stay comparable once the process changes.
The template
Every section, with the prompts that force the decision.
Section 01
Business outcome
Section 02
Records and stages
Section 03
Automation boundaries
Section 04
Measurement
After it is filled in
What the completed specification is actually consumed by.
Filling in the AI CRM Requirements Template produces an artifact, and an artifact on its own changes nothing. What matters is what consumes it afterwards.
Handed to the runtime, a completed sales specification stops being a document and starts being configuration. The authoritative record it names becomes the one the workflow reads; the stage transitions it defines become the events that trigger action; the ownership column becomes the routing rule. None of this requires the CRM to change — the system of record stays authoritative, and what the specification governs is the behaviour around it.
The part worth checking afterwards is the boundary drawn between automatic and approved. A specification that marks everything as requiring approval produces a workflow nobody uses; one that marks nothing produces a workflow nobody trusts. Most teams get this wrong in the same direction on the first pass and correct it once they have watched a week of real stage transitions.
Implementation path
How to actually fill it in.
- 01
Work through the template with the rep, the manager, and whoever owns the CRM, in the same room. Disagreement found here costs a conversation; found later it costs a migration.
- 02
Write the stage exit conditions as checks against fields that already exist, and add the missing fields before automating anything.
- 03
Record the numeric approval thresholds — discount, amount, term — as values rather than adjectives.
- 04
Pilot the workflow against a single segment with real records before rolling it out to the full pipeline.
- 05
Re-run the measurement section against the same population after the change, so improvement is attributable rather than asserted.
Controls this specification sets
Controls that matter.
Control 01
Automated writes respect the existing record owner rather than reassigning as a side effect.
Control 02
Matching runs before any create, and an ambiguous match raises an exception instead of producing a duplicate.
Control 03
Discount, pricing, and contract-term changes stay behind explicit human approval.
Control 04
Every automated CRM write records the event that caused it.
Worked examples
When teams reach for this one.
Before a CRM selection
Filling this in first turns vendor demos into a comparison against your own requirements rather than a tour of each product’s strengths.
Before automating pipeline hygiene
The field-authority section is what stops an enrichment workflow from overwriting a close date a rep set deliberately.
After a forecast disagreement
Most forecast disputes resolve to two stage definitions rather than two datasets. This is the artifact that settles it.
Limitations
What this template does not do.
- This specifies what the CRM must do; it does not select a vendor for you.
- Stage definitions here are yours, not an industry standard — do not expect them to map cleanly onto a vendor’s defaults.
- Automation boundaries assume the CRM can express them; some products cannot enforce field-level authority.
- The measurement section needs a baseline period before it produces anything comparable.
FAQ
Questions about the AI CRM Requirements Template.
Who should fill in the AI CRM Requirements Template?
The people who own the outcome, together. This template is written for smb sales teams, revops leaders, crm replacement projects, and the value comes from surfacing disagreement between them rather than from one person completing it alone.
How long does it take?
A focused session, usually one to two hours for a first pass. Sections that take much longer are normally pointing at a real disagreement, which is the template doing its job rather than failing.
Is it free, and is there a signup?
Free, with no gate. The Markdown download link at the top of this page returns the full template immediately.
What happens after it is filled in?
The completed template becomes the specification the build works from. You can hand it to ARIA to resolve into an objective and an execution path, hand it to an internal team, or use it to brief a vendor — the artifact is the same in each case.
Does this replace the tooling?
No. It specifies what the tooling has to do. Sales tools differ in how much of this they can enforce, which is itself useful information when you are comparing them.
How often should it be revisited?
When the process it describes changes, and on a scheduled review otherwise. A specification that no longer matches what runs is worse than none, because people still trust it.
More sales templates
Other sales specifications.
Sales Pipeline Blueprint
Map pipeline stages, exit criteria, next actions, ownership, and measurable conversion before changing CRM software.
Open the template →
AI Outbound Sequence Planner
Plan a bounded outbound sequence with target criteria, research inputs, message logic, stop rules, reply handling, and attribution.
Open the template →
Lead Qualification Scorecard
Create a transparent qualification model that combines fit, intent, timing, and human review instead of opaque AI scoring.
Open the template →
Keep exploring
Related reading and next steps.
Start with ARIA
Hand the brief to ARIA.
A completed template is a structured brief. Tell ARIA the objective and it resolves the systems involved and the execution path — so the specification becomes a running workflow, not another document.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Fill it in, then hand it to ARIA.
A completed template is a structured brief. ARIA can resolve it into the objective, the systems involved, and the execution path — so the specification becomes a running workflow rather than another document.