Most documents titled "AI sales enablement playbook" define the term and stop. This one assumes you already know what sales enablement is and want the operating detail: what to assemble, who owns it, what to write down, and what to check before anything reaches a customer.
Section 1: Objectives
Set no more than three objectives, each with a number and an owner. Objectives that describe activity rather than outcome are the most common reason these programmes cannot be evaluated later.
| Objective | Metric | Owner |
|---|---|---|
| Respond to qualified inbound faster | Median time to first response | Sales manager |
| Increase time spent selling | Customer-facing hours as a share of the working week | Sales director |
| Improve pipeline data quality | Percentage of open opportunities with next step and close date | Sales operations |
Section 2: Required inputs
Assemble these before selecting any tool. If an input is missing, that gap is your first project.
- Ideal customer definition with the firmographic criteria written as filters, not adjectives.
- A clean target account list with consistent identifiers. We use Companies House records as the spine so every other source can be matched against something stable.
- A documented sales process with stage definitions and exit criteria.
- An approved messaging set: what you do, who you serve, what you do not do, and the three objections you hear most.
- Evidence library: permissioned case studies, references and any verified outcome data.
- Product and pricing facts in a form that can be quoted without interpretation.
- A current baseline for each objective metric, covering at least four weeks.
Section 3: Roles and responsibilities
| Area | Sales leadership | Salespeople | Marketing | Operations | Technical |
|---|---|---|---|---|---|
| Objectives and thresholds | Own | Input | Input | Support | — |
| Workflow documentation | Approve | Input | — | Own | — |
| Messaging and evidence | Approve | Input | Own | — | — |
| Use-case selection | Own | Input | Input | Support | Feasibility |
| Prompt and knowledge standards | Approve | Input | Own | Support | Support |
| Data controls and access | Approve | Comply | Comply | Own | Implement |
| Testing before release | Approve | Participate | Participate | Own | Implement |
| Adoption and training | Own | Participate | Support | Support | — |
| Measurement and reporting | Review | — | Support | Own | Support |
| Customer-facing output quality | Accountable | Accountable | Support | — | — |
Section 4: Workflow mapping and use-case scoring
Map the workflow as it is performed, then score candidates. A workable scoring template, each dimension out of five:
- Frequency — how often the task occurs per person per week.
- Time cost — measured, not estimated.
- Error tolerance — whether a human reviews the output before it matters commercially.
- Data readiness — whether the required information is already accessible and clean.
- Strategic fit — whether improving this moves one of your three objectives.
Rank by the product of the scores and start with the highest that has an error tolerance of four or five. Detailed guidance on pilot sequencing sits in how to operationalise AI without disrupting sales teams.
Section 5: Prompt and knowledge standards
Prompts are operational assets. Store them centrally, version them, and hold them to a written standard. Ours requires every production prompt to specify role, task, source material, constraints, output format and refusal behaviour.
The two clauses that matter most are the source restriction and the explicit instruction to report missing information rather than fill the gap. Without them, briefs read beautifully and contain invented detail.
Knowledge standards apply to the material the system draws on: one approved description of each service, one current price list, one statement of exclusions, and a dated review cycle. Conflicting internal documents are the most common cause of inconsistent output.
Section 6: Data controls
- Classify what may be used: public information, internal commercial data, customer confidential data, personal data.
- State where each class may be processed and by which tools.
- Apply the same lawful-basis and minimisation thinking you would apply to any other processing of personal data.
- Log who accessed what, particularly for enrichment and prospecting activity.
- Set a retention position for prompts and outputs that contain customer information.
Section 7: Testing before release
Build a fixed test set of twenty real cases with known correct answers — accounts you know well, enquiries you have already handled. Run every prompt change against it. Score each output on four criteria: factual accuracy, completeness, tone fit and whether it followed the missing-information rule. Nothing goes live below 90 per cent on factual accuracy.
Re-run the test set whenever the underlying model, the prompt or the source material changes. Silent model updates are a real operational risk, and a fixed test set is the cheapest way to detect drift.
Section 8: Deployment and adoption
- Release to a pilot group of three to six, including a sceptic.
- Switch off the step being replaced on day one.
- Run role-specific training on live accounts, sixty to ninety minutes.
- Provide a one-click way to report a bad output, and respond to every report within a day.
- Review weekly for four weeks against the objective metric and the adoption metric.
Section 9: Measurement
Report three things monthly: the objective metrics against baseline, adoption (weekly active users, not licences), and quality signals (corrections, clarifications, disputed scope). Full metric definitions and collection methods are set out in how to measure success in AI-enabled sales.
Section 10: Optimisation and scaling
Optimise in this order: source material first, prompt second, model third, tool last. Most quality problems attributed to the model are caused by conflicting or out-of-date source material.
Scale only when the pilot beat its baseline for three consecutive weeks, adoption held without prompting, and administrative load did not increase. When you scale, extend to the adjacent workflow step rather than to a new department — the shared inputs are already in place, so the second use case costs a fraction of the first.
Risks and common failures
- No single source of truth. Two price lists produce two answers and destroy trust in the whole system.
- Prompt sprawl. Individually maintained prompts drift; centralise and version them.
- Unreviewed customer-facing output. The fastest way to lose the credibility that funds the programme.
- Measuring adoption by licences. It flatters the report and hides the problem.
- Scaling on enthusiasm. If the numbers did not move, expanding will not fix it.
Key takeaways
- Set three outcome objectives with owners, then assemble the inputs before choosing tools.
- Give every responsibility area a single owner using the table above.
- Treat prompts as versioned operational assets with a written standard.
- Run a fixed twenty-case test set before every release and after every model change.
- Optimise source material before prompts, prompts before models, models before tools.