The question that decides whether it makes sense
A sales rep spends a good part of the week on things that aren’t selling: preparing meetings, writing proposals, updating the CRM, and chasing dormant opportunities. A copilot goes after that part. The question to ask first is uncomfortable but necessary: does your CRM reflect reality? If the team logs opportunities after the fact and from memory, any system built on top will inherit that fiction.
What it does
Prepares the meeting. Before a meeting, it pulls together the account history, what was discussed last time, order status, open issues, and any public news about the client. The rep walks in having read one page in three minutes, instead of relying on what they think they remember.
Drafts the proposal. It takes the catalog, the terms that apply to that client, and what was discussed in the meeting, and produces a draft in the usual structure. The rep edits and signs off. The savings here are direct and easy to measure: hours of writing per proposal.
Keeps the follow-up alive. It spots stalled opportunities, suggests the next step, and drafts the email. It doesn’t send it on its own: communication with a client is one of those things that shouldn’t go out without someone reading it.
Updates the CRM. From the meeting notes, it fills in the fields and records what was agreed. In practice, this is the feature sales teams appreciate most — and the one that gets them using everything else.
The data you need
A CRM with API access, the catalog and commercial terms stored somewhere structured, and the history of past proposals — which is what teaches the system how your company writes. If minutes or notes from previous meetings exist, even better; if not, you start building that material from day one.
How we measure it
Time from request to proposal sent, proposals per rep per month, the share of opportunities followed up within the agreed time, and CRM data quality (the share of fields filled in). Conversion rate too, but carefully: it depends on too many factors outside the copilot to credit or blame it within a single quarter.
Where it fails
The first risk is trust: one proposal with a made-up price or term burns the system for good. Commercial data must come from the source and be labeled as such, not from what the model happens to remember; that’s what RAG on the real catalog is for.
The second is adoption. If the copilot adds steps instead of removing them, the team will drop it within three weeks — and nobody will say so out loud. Measure real usage from the start.
The third is personal data: preparing a meeting by combining information about an individual has clear limits under the GDPR, and logging what is looked up and why is part of the system’s governance.