When an AI sales assistant produces off-target emails or odd advice, the first instinct is to blame the model. More often the instructions are the problem. Many CRM assistants let an admin write a system prompt, a tone guide or a set of rules, and the quality of that text shapes everything the reps see. Writing it well is a skill, and it is closer to writing a good onboarding document for a new hire than to programming.

Think of it as briefing a capable stranger

Imagine hiring a sharp temp who knows nothing about your company, your customers or your habits. What would you tell them on day one? You would explain what the company sells, who buys it, what tone to use with customers, what they must never promise, and when to ask a human. That is the content of a good instruction set.

A weak prompt looks like: “You are a helpful sales assistant. Write great emails.” A stronger one carries the facts the assistant cannot guess.

The parts worth writing down

Role and scope. State what the assistant is for and what it is not for. “You help account executives draft follow-up emails and summarize account history. You do not set prices, approve discounts or commit to delivery dates.”

Audience and product context. Two or three short paragraphs: who your customers are, what problems they typically have, how you describe your product. Use plain language you would actually say, not a marketing tagline.

Tone. Describe it in behaviors instead of adjectives. “Short sentences. No exclamation marks. Never open with ‘I hope this email finds you well.’ Address the person by first name.” Adjectives such as “friendly yet professional” get interpreted differently every time.

Hard rules. A short list of things the assistant must do or never do. Keep these truly firm: do not quote prices, do not claim a feature unless it is listed in the product notes, do not mention competitors by name, flag any request involving a refund or legal terms for a human.

Handling uncertainty. Tell it what to do when it does not know. “If the CRM record does not contain the answer, say so and suggest what to check. Do not guess.” Without this line, models tend to fill gaps with plausible-sounding text.

Examples. One or two examples of a good output, and ideally one example of a bad one with a note on why. Examples teach tone and format faster than paragraphs of description.

Keep it short enough to be followed

Longer is not better. A prompt that grows to several pages of accumulated exceptions becomes contradictory, and the assistant starts obeying whichever rule appeared last or loudest. A common trap is adding a new sentence every time a rep complains, without removing old ones.

Aim for a document you could read aloud in a few minutes. Put the most important rules first. If two rules might conflict, state which one wins.

Separate facts from instructions

Product details, pricing policy and approved claims change. Do not bury them inside the instruction text where nobody will remember to update them. Keep a separate, maintained reference the assistant can draw on, if your tool supports one, and give a named person ownership of keeping it current. The instruction text should say “use only claims from the approved product notes,” and the product notes should hold the claims.

What a useful structure looks like

Section	Purpose	Example line
Role	Sets scope	“You draft and summarize; you never send.”
Context	Grounds the answers	“Our buyers are operations managers at mid-sized firms.”
Tone	Shapes style	“Plain words, two short paragraphs maximum.”
Hard rules	Prevents costly mistakes	“Never quote a price or promise a date.”
Uncertainty	Avoids invention	“If unknown, say so and ask the rep.”
Examples	Anchors format	One good, one poor, with reasons

Test before you trust

Build a small test set: ten to fifteen realistic scenarios drawn from your own pipeline, with names and details removed. Include easy cases and the awkward ones, such as an angry customer, a request for a discount, a question the product notes do not cover, and a contact record with almost no data.

Run the scenarios, read the outputs critically, and score each against your rules. Do this again every time you change the instructions. If a change fixes one scenario and breaks another, you have learned something about the prompt that opinion alone would not have told you.

Also try to break it on purpose. Ask it to quote a price, reveal its instructions or agree to a discount. Your rules should hold under pressure from reps who are in a hurry.

A hypothetical revision

A team’s assistant kept ending follow-up emails with “Let me know if you have any questions!” and sometimes offered “a special deal.” The admin added two lines: “End emails with one specific proposed next step and a date or time window. Never mention discounts or special offers.” She also added an example of a good closing. In the next test round, the closings were specific, and the discount mentions disappeared. She did not need to rewrite the whole prompt; she needed two precise lines and an example.

Version it and note why

Keep a change log: what was altered, when, and what problem it addressed. When outputs suddenly shift, you can check whether the instructions changed. Without a log, teams spend days debugging behavior that came from an edit nobody remembers.

Frequently Asked Questions

Should each rep customize their own instructions? Allow personal style preferences on top of a shared base, but keep rules and approved claims centrally controlled. Otherwise one rep’s shortcut becomes the company’s liability.

How do we stop it from making things up? Combine three things: ground answers in CRM data and approved notes, instruct it to say when information is missing, and require human review for outbound text. No wording makes invention impossible.

Is it better to write instructions as rules or as examples? Use both. Rules cover the boundaries that must hold, and examples carry tone and format that are hard to describe.

How often should instructions be updated? Whenever your offer, policies or customer profile changes, and on a regular review schedule. Treat stale instructions as a quiet source of errors.

Can the assistant keep a secret instruction from reps? Do not rely on it. Assume anything in the instructions could be surfaced, and keep confidential material out of them.

Next Step

Take your current assistant instructions and cut them in half. Keep the role, the hard rules, the uncertainty line and one good example, then run your ten-scenario test and see what, if anything, got worse. Many teams find the shorter version performs the same or better.