# How do you create different enablement materials for SDRs versus AEs versus sales engineers?
> How to build enablement for SDRs, AEs, and sales engineers from one core message, with the same pitch rewritten for each role and a test for each kit.

Source: https://mokk.ai/pmm-questions/content-campaigns/enablement-by-sales-role (updated 2026-09-22)
Markdown: https://mokk.ai/pmm-questions/content-campaigns/enablement-by-sales-role.md

Keep one messaging source and build each kit for the moment that role faces. SDRs need a trigger, a persona opener, and replies to common brush-offs. AEs need discovery questions, a business case, and help with competitors and new stakeholders. Sales engineers need technical depth, security answers, and a demo flow that adapts to the buyer’s stack. Test each kit with a leader from that group.

## What role-based enablement has to get right

Handing every seller the same deck ignores that their jobs are different. An SDR has about thirty seconds to earn a reply. An AE runs a deal over weeks and has to reach several people. A sales engineer has to survive a technical buyer who is looking for the flaw. A strong answer knows those moments and serves each one without splitting the story.

Communication carries as much weight as influence on this one. Adjusting detail to the audience is part of the rubric’s Strong level, and here there are three audiences.

What each sales role needs from enablement
| Role | Their moment | What the kit needs | What to leave out |
| --- | --- | --- | --- |
| SDR | A cold email or call, with seconds to earn attention | A trigger to reach out on, an opener by persona, replies to the top two brush-offs | Architecture, pricing detail, competitive depth |
| AE | Discovery through close, across several stakeholders | Discovery questions, a business case template, competitive and pricing help, a way to bring in more stakeholders | Scripted openers and deep technical detail |
| Sales engineer | Demos and technical evaluation | Architecture notes, security answers, a demo flow that adapts to the buyer’s stack | Value messaging they will never say |

## One message, rewritten for three roles

The example is an API monitoring company selling to engineering teams at mid-size companies. The core message is that teams find broken integrations before their customers do. Here it is written once, for everybody.

**First draft (invented example)** "Our platform gives engineering teams full visibility into every API they depend on, with real-time alerts, historical performance data, and root-cause analysis, so they can catch integration failures before customers notice and reduce time spent on incidents."

It is accurate, and no role can use it as written. An SDR can’t send it, and an AE can’t build a business case from it. A sales engineer will be asked what “full visibility” means within a minute.

**Rewritten for SDRs (invented example)** "Saw your team shipped a new payments integration last month. When a partner API slows down, most teams hear about it from a customer first. Open to ten minutes on how teams like yours catch it earlier?"

**Rewritten for AEs (invented example)** "Ask how the last partner outage was found, and how long that took. Then put numbers on it. Hours of engineering time per incident, tickets opened, any credits paid to customers. The case is that catching it twenty minutes earlier pays for the product after one or two incidents a year."

**Rewritten for sales engineers (invented example)** "Show the alert firing on a synthetic check against their staging environment, then walk the trace to the partner endpoint that slowed down. Be ready for questions about where data is stored, how the agent affects latency, and what happens when their own network is the problem."

All three carry the same promise. Each is shaped for what that person is doing at that moment, which is the skill the question is asking about.

## How the role-by-role answer sounds

**Strong answer (invented example)** "Same story, different depth, because each role has a different job in the deal. I’d start from one messaging source. At an API monitoring company, that’s the idea that teams find broken integrations before their customers do. SDRs have about thirty seconds, so their kit is a trigger to reach out on, like a new integration announced in a company’s changelog, an opener by persona, and replies to the two brush-offs they hear most. AEs run the deal, so they need discovery questions about the last outage, a business case template that turns incident hours into cost, and help getting the engineering manager and the head of platform into the same conversation. Sales engineers need architecture notes, security answers, and a demo flow they can point at the buyer’s own staging environment. Then I’d ask one leader from each group to use the kit for two weeks and tell me what they skipped. What they skip tells me where I over-built."

AEs often get the least help with the business case, and naming it specifically moves the answer up. An Exceptional version also covers handoffs, such as what the SDR passes to the AE, so the buyer never hears the pitch start over.

## A quick test for each enablement kit

1. Hand the SDR kit to an SDR and ask for a first email in five minutes. If they can’t write one, the kit is too long.
2. Ask an AE to explain the business case back to you in their own words.
3. Have a sales engineer run the demo flow for a skeptical colleague playing a staff engineer.
4. Read all three kits side by side and check that the core promise is the same in each.

## Follow-ups on role-based enablement

Follow-up questions about enablement for SDRs, AEs, and sales engineers
| When they press | What they are weighing | What to say |
| --- | --- | --- |
| How do you keep messaging consistent across three kits? | Whether you have a single source | Build every kit from one messaging document, and review all three together when it changes |
| SDRs and AEs disagree about the pitch. Who wins? | Handling conflict | Look at what converts at each stage. SDR openers are judged by replies, and AE pitches by progression. |
| Which role would you build for first? | Prioritizing | The role where the pipeline leaks most, based on stage conversion, instead of the loudest team |
| How would you enable a role that doesn’t exist yet? | Planning ahead | Shadow the closest current role, draft a thin kit, and revise it after the first few hires use it |

## More questions in this category

- [Enablement for an upmarket move](https://mokk.ai/pmm-questions/content-campaigns/enablement-for-upmarket-move)
- [Building sales enablement](https://mokk.ai/pmm-questions/content-campaigns/build-sales-enablement-from-scratch)
- [An asset that improved win rates](https://mokk.ai/pmm-questions/content-campaigns/sales-asset-that-improved-win-rates)
- [Sales selling off-message](https://mokk.ai/pmm-questions/content-campaigns/sales-selling-off-message)
- [All content and campaigns questions](https://mokk.ai/pmm-questions/content-campaigns)

## Frequently asked questions

**Should each role get its own playbook?** Give each role a focused kit, and build all of them from the same core message. Separate stories confuse buyers who talk to more than one person on your team.

**How do I answer if I haven’t worked with sales engineers?** Say how you would learn their needs, such as sitting in on demos and asking what buyers press on. Then describe what you would build from that. The instinct to learn from them first is what gets scored.

## Practice

**Answer it out loud.** A Mokk session asks this question, follows up on your answer, and scores it on five competencies.