AI for salespeople: preparing follow-ups and drafts without losing control

A salesperson spends a good part of the day preparing: rereading past exchanges, writing up the summary of a call, putting together a draft proposal with information scattered across email, notes, and the price list. It's necessary, repetitive work, and it's the point where an artificial intelligence system can help without touching anything sensitive — on one condition: that what it produces gets read by a person before it goes out.

There's a single distinction that everything else rests on: preparing isn't deciding, and it isn't sending.

What it can prepare and what it must not do

The boundary isn't technical, it's about accountability. On one side are tasks where a mistake costs a re-read; on the other, tasks where a mistake costs a commitment made to a customer.

• It can summarize a long request or a series of messages, noting where each piece of information comes from.
• It can draft a reply or the cover letter for a proposal.
• It can reconstruct a customer's history before a call: what they've bought, what they'd asked about, what's still pending.
• It can suggest next actions and questions to ask, listing what's missing to put together an offer.

• It must not calculate or make up a price: prices come from the price list and the company's rules, and generated text isn't the source of a price.
• It must not make commitments about deadlines, availability, warranties, or terms.
• It must not send anything to a customer without a person having read it.
• It must not choose the recipient, unless the process has already determined it.

Sources: authorized data, not "everything there is"

A useful assistant is an assistant with boundaries. The question to ask isn't what it could read, but what it has the right to read for this task and this person.

• List the allowed sources: incoming requests, deal notes, product sheets, approved documents. Whatever isn't on the list doesn't go in.
• Respect people's permissions: if a salesperson can't see colleagues' deals, the system must not show them inside a summary.
• Keep approved documents separate from drafts: old or never-validated text that ends up in a proposal is a mistake the customer will see.
• Decide what should happen when information is missing: the correct answer is to leave a flagged gap, not fill it with a plausible-sounding sentence.

One case: from request to draft

Illustrative example. A request comes in through the site's contact form: a company asks for a quote on a supply order, with a technical attachment and a confusing description of its needs.

1. The system gathers what it's authorized to: the text of the request, the attachment, the customer's record if it already exists in the business management system, and previous exchanges.
2. It produces a ten-line summary: what's being asked, for when, what's unclear. It flags three points as "to ask the customer."
3. It drafts a reply following the structure of already-approved proposals, leaving the price and timing fields blank.
4. The salesperson reads it and fixes two things: the quantity, because the attachment showed a different figure than the text, and a reference to a process the company no longer performs.
5. They enter prices and timing taken from the price list and actual availability, not from the draft.
6. They send it. The sent version stays on record in the deal, along with the date of the next contact.

The gain isn't the writing: it's that the salesperson starts from a full page instead of a blank one, and the questions to ask the customer are already isolated. The two corrections in the fourth step aren't a failure of the system: they're the reason that step exists.

The checks before sending

There are four, always the same ones, and it helps to have them written down where people work, not just kept in memory.

1. The amounts match the price list or the approved quote.
2. There are no unauthorized commitments: delivery dates, warranties, availability, discounts.
3. The recipient is the right one, and no references to other customers are left in the text.
4. The next action is stated, with a date and an owner.

If these checks take more time than the prep work saved, the system isn't doing any good. It's a useful signal: it usually means the drafts are too long or the sources aren't reliable.

Recording the outcome, not just the sending

What was sent needs to flow back into the sales process: which version, to whom, when, with what outcome. This serves three practical purposes: knowing what was promised when the customer calls back months later, understanding which proposals work, and noticing whether the system keeps making the same kind of mistake.

For a few weeks, it's worth keeping a simple count, done by the salespeople themselves: how many drafts were used almost as they were, how many rewritten, how many thrown out. It's the most honest way to decide whether to extend the use, fix it, or stop it.

What this guide doesn't cover

Here we cover assistance with preparation and writing. Calculating the quote — price lists, discount rules, configurations, margins — is a different matter and needs to be solved with tools where the same input always produces the same result. Organizing deals, responsibilities, and next actions in the sales management system also has its own dedicated guide.