Prompts are not magic words. They are specifications. The same five parts show up in every reliable one: a role, a task, context, constraints, and examples. The teams that get useful AI output are the ones who write prompts like code and test them like code.
Prompt engineering is the practice of designing instructions to AI systems so they produce consistent, useful output. For sales teams, that means writing reusable templates for discovery summaries, email drafts, deal risk reads, and objection handlers, then testing them against real deals before deploying. A good CRM ships a tested library of these prompts and lets each tenant customize the parts that reflect their own motion.
Five things to understand before writing a single prompt, and the one reason most sales AI rollouts quietly stall by the second quarter.
A prompt is a written specification telling the AI who it is, what to do, with what context, under what constraints, in what format. The teams that get consistent output treat prompts the way engineers treat function signatures: inputs, outputs, and behavior pinned down in writing before anyone runs them in production.
Every reliable prompt names a role ("You are a sales enablement coach"), a task ("Summarize this discovery call"), context (the transcript, the deal, the ICP), constraints (word count, tone, forbidden topics), and examples (two or three model outputs). Drop any one of the five and output quality falls off a cliff.
Chain-of-thought prompts ask the model to think step by step before answering, which lifts reasoning accuracy on judgment tasks like deal risk. Structured output prompts ask for JSON or a fixed template, which makes the answer safe to feed into automation. Pick based on whether a human or a workflow is reading the result.
Discovery call summary, follow-up email draft, deal risk assessment, objection handler, and competitor battlecard. These five show up in every revenue team because they are the five writing tasks reps already do. A good prompt library ships all five tested, with each tenant able to swap the voice, the ICP, and the forbidden topics.
Prompts regress silently. Teams that keep output quality high maintain an evaluation set of ten to twenty real inputs with graded "good" answers, and rerun the full set every time a prompt changes. The eval is the contract. Without it, every prompt tweak is a guess, and every model update is a surprise.
The dirty secret of sales AI is that most rollouts have no version control, no eval set, and no deployment story. Prompts live in a Google Doc that one person edits. When quality drops nobody knows why. A platform that versions prompts, tests them, and deploys them is the difference between a feature teams use and a demo nobody opens twice.
Treat the prompt like a specification. A good one tells the AI who it is being for the length of this task, what the task actually is, which inputs count as context, which rules must not be broken, and what a correct answer looks like. Change the role, the task, or the format and the output shape changes with it. The teams that write prompts loosely get loose output; the teams that pin all five parts down get work they can ship to a customer.
The role sets vocabulary, defaults, and the mental model the AI brings to the problem. "You are a senior sales coach reviewing a discovery call" produces a different answer than "You are a note-taker." Keep the role specific to the task. Generic roles like "helpful assistant" waste the slot and leak into unprofessional tone.
One verb, one object, one deliverable. "Summarize this discovery call into five bullets covering pain, budget, timeline, decision process, and next step." Avoid stacking three tasks into one prompt. A multi-task prompt returns a tangled answer, and the second task is almost always done worse than the first.
The transcript, the deal record, the ICP definition, the previous emails, the pricing sheet. Context is where retrieval-augmented generation lives, pulling the right records in instead of pasting them by hand. Thin context produces generic output. Rich, filtered context is what makes an answer feel like your company wrote it.
Word count caps, forbidden topics, required brand voice, mandatory calls to action, prohibited model names. "Reply in 80 words or fewer, no em-dashes, do not mention pricing, close with a scheduling link." Constraints are what let legal and brand sign off on using an AI output in customer-facing surfaces.
Few-shot examples teach the AI what a correct answer looks like in your voice far better than any instruction. Two examples beat one; three or four beats two. Pick examples that cover the edge cases, not the easy ones. The examples double as the start of an eval set.
Markdown bullets, JSON matching a schema, a plain paragraph, a fixed email template. Format is where structured output lives. If a workflow is going to read the answer, demand JSON and validate it. If a rep is going to read it, specify the heading structure and the bullet style.
The two most useful prompt shapes in a sales motion look very different on paper and solve very different problems. Chain-of-thought prompts ask the AI to think out loud before answering, which raises accuracy on judgment calls where "obvious" is a trap. Structured output prompts ask for a strict shape (JSON matching a schema, a fixed template) so the answer can be scored, stored, and fed into a workflow. Most production prompts in a CRM combine both: think step by step, then emit the final answer in the schema below.
Ask the AI to list its reasoning before the final answer. "First, list the three biggest risks in this deal. Then score each one on likelihood. Then output the single highest-risk item and a one-sentence mitigation." Reasoning-first prompts lift accuracy on anything that looks like a judgment call: deal risk, forecast category, lost reason, objection severity.
Chain-of-thought earns its keep on tasks where the answer requires inference: "Is this deal at risk?" "Which objection matters most?" "What should the next step be?" It is overkill for tasks that are closer to transcription, like extracting the attendees from a meeting invite or formatting an existing email into a template.
Specify a JSON schema and ask the AI to return matching output. "Return {risk_level: low|medium|high, top_risk: string, mitigation: string}." Validate the response against the schema and reject anything that does not match. Structured output is what turns an AI answer into a field update, a routing rule, or a Slack notification.
Any time the answer feeds into a workflow, a field, a filter, or a report. Structured output is what makes AI output safe to automate on. If a human is the final reader and the shape is "a well-written paragraph," structured output just gets in the way; use markdown with specified headings instead.
The pattern most production sales prompts settle on: ask the AI to reason step by step in a scratchpad, then emit a final JSON block matching a schema. You get the accuracy of chain-of-thought and the automatability of structured output. The scratchpad is discarded; the JSON is stored on the record.
Brand voice is not a prompt shape; it is a constraint block that applies to every shape. The team maintains one voice specification ("concise, direct, no em-dashes, no corporate throat-clearing") and includes it as a trailing constraint in every customer-facing prompt. Voice drift is the first sign a prompt library has no central ownership.
Over hundreds of sales AI rollouts, the same five prompt templates show up as the ones reps run every day. Every other prompt in the library is a variation on one of these. A good CRM ships all five tested, with a tenant-level customization layer so the ICP, the brand voice, the forbidden topics, and the preferred structure can be swapped in without rewriting the prompt from scratch.
Role: senior sales coach. Task: summarize the call into pain, budget, timeline, decision process, next step. Context: the transcript plus the deal record. Constraints: 80 words, no em-dashes, flag anything the rep did not confirm. Format: markdown bullets. The AI writes the summary; the rep edits in two minutes instead of writing in fifteen.
Role: the rep as named sender. Task: draft the next email given the last three messages, the meeting notes, and the next step. Context: thread history plus playbook. Constraints: brand voice, closing with a Calendly link, no pricing specifics. Output: subject plus body in markdown. Reps keep the ones that already sound like them.
Role: deal review lead. Task: list the three biggest risks on this deal and the single mitigation most likely to work. Context: the deal record, activity timeline, stage history, and MEDDIC fields. Format: chain-of-thought reasoning, then a JSON block with risk_level and top_risk. Managers read the JSON in a dashboard, not the transcript.
Role: product-literate seller. Task: given an objection and the deal context, return the recommended response from the playbook plus a tailored opening sentence. Context: the objection text, the deal record, the enablement playbook. Constraints: do not invent facts; cite which playbook entry the response came from. Output: markdown.
Role: competitive analyst. Task: compare the current deal against the named competitor using the battlecard. Context: the battlecard, the account, the stakeholders. Constraints: do not mention features we have not shipped; flag areas where the battlecard is older than six months. Output: structured sections (where we win, where we lose, where to focus).
Summaries, follow-ups, risk reads, objection replies, and competitive framing are the five things sales reps already write in their heads every day. Templating these first is where the hours come back. Fancier use cases (full account plans, multi-threaded strategies) land after these five are reliable and the library is actually trusted.
Prompts regress silently. A tiny edit, a model update, a context length change, and suddenly the discovery summaries get sloppier and nobody notices for three weeks. The teams that keep sales AI quality high treat prompts like code: an evaluation set grades every change, versions are tracked, deployments are deliberate, and per-tenant customization is a layer on top of a tested base. The CRM that ships this plumbing is the one teams actually keep using.
Pick ten to twenty representative inputs (real transcripts, real deals, real objections) and write the "correct" answer for each. Rerun the full set every time a prompt changes and compare the output against the graded answer. If quality drops on any input, the change does not ship. The eval set is the only honest judge of a prompt edit.
The current prompt is v12. Last week it was v11. The eval scores for every version are stored. When a sales manager says "the summaries got worse this week," you can diff the two versions and run both against the eval set in minutes. Prompts without versions are prompts nobody owns.
Promote a new prompt version from dev to a canary tenant to the full fleet, with eval scores at every stage. The ability to roll back one prompt without touching the others is what makes the system safe to experiment on. Deployment story is where most in-house sales AI projects quietly give up.
Measure which prompts get run, which outputs reps accept, which reps edit before sending, and which prompts get overridden by a tenant-specific version. Low acceptance means the prompt is wrong for the audience. High override volume means the base library needs the tenant's pattern upstreamed.
The platform ships a tested base library. Each tenant customizes the voice, the ICP, the forbidden topics, the playbook references, and the specific examples. Updates to the base library land as suggestions, not forced overwrites, so your custom prompts never get stomped by a vendor release.
The prompts live where the deals live, because the context the prompts need (ICPs, deals, activity, playbooks) also lives there. Running sales AI off a side tool means paying to shuttle customer records back and forth. A CRM that owns the prompt library and the records in one place is Strkr AI running on data that is already there.
Discovery summaries, follow-up drafts, deal risk, objections, and battlecards all run on prompts the platform has evaluated against real sales motions. Each tenant customizes voice, ICP, and playbook references without rewriting the base. One login, one data model, one place to version and measure every prompt.
A rep does not need to learn the underlying patterns to use a well-built library, in the same way a rep does not need to learn SQL to run a report. What a sales operations team needs is one or two people who understand the five-part prompt structure and the eval loop, so the library stays honest. The CRM should ship the base prompts tested and let that owner customize them.
The system prompt is the fixed instruction block the AI sees before any user input, used to set the role, constraints, and defaults for every interaction in a feature. The user prompt is the specific task the rep or workflow is submitting. Prompt engineering touches both: a sturdy system prompt lets the user prompt stay short and focused.
Three measures matter. Eval score: how well the prompt scores against a set of real inputs with graded answers. Acceptance rate: how often reps use the output without rewriting it. Override rate: how often a tenant overrides the base prompt with a custom one. A healthy prompt has a stable eval score, high acceptance, and low override volume outside of brand voice tweaks.
Retrieval-augmented generation (RAG) is the pattern of pulling relevant records (deals, contacts, playbooks, past emails) into the prompt as context before the AI answers. Prompt engineering is the broader practice of designing the full instruction, with retrieval filling the context slot. A sales prompt without retrieval is working from thin air; a sales prompt with retrieval reasons over the actual deal.
Buy the base library, own the customization. Writing prompts from scratch means paying to rediscover the five-part structure, build an eval set, and figure out which five templates matter. The parts worth owning are the voice, the ICP, the playbook references, and the specific examples that reflect how your team actually sells. Everything else is table stakes a platform should supply.
An eval set is a collection of representative inputs (real transcripts, real objections, real deals) with a graded "correct" answer for each one. Ten to twenty entries is enough to catch most regressions on a single prompt. Larger libraries (fifty-plus) are useful once a prompt is deployed broadly and small quality shifts matter financially. The point is to make prompt changes testable, not to be exhaustive.
Only if the architecture is wrong. A multi-tenant AI feature must scope the retrieval context to the current tenant before the prompt is built, so no cross-tenant record ever enters the AI call. Prompt engineering alone cannot patch a leaky retrieval layer; the platform has to enforce the boundary. Ask any vendor to describe their tenant isolation story before signing.
Base prompts stabilize within a few iterations and should not need frequent edits once the eval scores are strong. Tenant-level customization (voice, examples, playbook references) gets updated whenever the underlying playbook or ICP changes, which for most teams is quarterly. Model upgrades can also force a prompt revisit; the eval set is what tells you whether the old prompt still works on the new model.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
