A sales copilot that does the prep, the notes and the follow-up
Give every rep a briefed start to each call, a written record afterwards and a CRM that stays current, with the rep approving every change the AI proposes.
Reps are paid to sell and spend their day on admin
Before a call, a rep opens six tabs: the CRM record, the last email thread, the previous meeting notes, the pricing sheet, LinkedIn and a deck. After the call, the notes go into the CRM late, partially or not at all. Pipeline reviews then run on stale data, and forecasting becomes guesswork.
Generic "AI assistants" bolted onto email do not fix this, because they cannot see the account history. The fix is a copilot with permissioned access to the CRM, mailbox and call records, that drafts the work and asks the rep to approve it.
How it works
From calendar invite to updated opportunity
The copilot reads with the rep's permissions and writes only what the rep approves. Each approval, rejection and edit is logged, which also tells us which proposals are safe to automate later.
1. Gather the context
A calendar event or a finished call triggers the copilot. It pulls the account record, open opportunities, recent emails, the last transcript and the relevant product pages, filtered by what the rep is allowed to see.
2. Draft the work
Before the call: a one-page brief with history, open questions and likely objections, each line sourced. After the call: structured notes, a follow-up email and a summary for the account team.
3. Propose, approve, record
The copilot proposes stage, next step, close date and tasks. The rep approves or edits in the CRM sidebar. Approved changes are written through the CRM API and logged with the reasoning.
What you get
What ships with the copilot
Pre-call briefs
Delivered to the rep's inbox or CRM sidebar an hour before each meeting, with sources shown for every claim and a short list of suggested questions.
Call notes and follow-ups
Structured notes from transcripts, using our meeting intelligence pipeline, plus a drafted follow-up email the rep sends or discards.
Approval-gated CRM writes
Proposed field updates appear as a checklist. The rep ticks what is right; the rest is dropped. Write rules are configurable per field and per role.
Connectors built as MCP servers
CRM, mailbox, calendar and call platform are exposed to the model through MCP servers with scoped, auditable permissions, so the same connectors serve future agents.
Adoption and accuracy dashboard
Brief open rate, note acceptance rate, proposals approved versus rejected, CRM completeness over time, and model cost per rep per week.
Guardrails we build in
Accuracy thresholds: briefs only include statements with a retrieved source, and the acceptance rate of notes must clear an agreed bar in the pilot before rollout widens. Human-in-the-loop: every CRM write and every outbound email is approved by the rep; automation is enabled per field later, by you. Audit trail: sources, draft, proposal, rep decision and the final write are stored together. PII handling: prospect data stays within your tenant's region, retention follows your CRM policy, and the copilot never sees accounts outside the rep's permissions, as set out in AI data privacy. The full control set is described under AI security and governance.
Typical rollout
One team first, then the floor
Map the motion (2 weeks)
Shadow a sales team, catalogue the systems reps actually use, agree which CRM fields matter for forecasting and baseline their completeness.
Connect and draft (4 weeks)
Build the connectors, the retrieval layer and the brief and note templates. Evaluate on historical accounts until reps rate the drafts as usable.
Pilot with one team (4 weeks)
Ten to twenty reps use the copilot daily with full approval gating. We tune templates weekly from rejection reasons.
Roll out and automate (2–4 weeks)
Extend to further teams, allow automatic writes for the safest fields and hand over with runbooks. Ongoing tuning is available under AI agents and automation.
Illustrative example
What a first release usually looks like
Illustrative scenario, not a client case
A business-to-business software vendor runs a sales team of a few dozen reps on Salesforce Sales Cloud, with calls recorded in a conferencing tool. Pipeline reviews are slow because next-step and close-date fields are often weeks out of date. In the pilot, one regional team receives a brief before every external meeting and a drafted note and follow-up afterwards. Reps approve most note drafts after small edits and reject a minority of proposed stage changes, which the team uses to tighten the stage definitions. By the end of the pilot, the CRM fields the sales leader cares about are updated the same day as the call rather than at the end of the week, and the forecast review takes a fraction of the time. The second phase extends the copilot to the remaining teams and allows automatic updates for the last-contact and next-step fields only.
If your reps live in Salesforce, compare this with Sales Cloud native features before deciding how much to build.
Not by default. It proposes field updates, tasks and follow-up emails; the rep approves them with one click. After the pilot you can allow automatic writes for low-risk fields such as last-contact date, while stage changes and amounts stay behind approval. Every write is logged under the copilot's own identity.
We already use Salesforce. Should we use Agentforce instead?
Often, yes, and we build both. If your data and reps live in Salesforce, Agentforce and Einstein keep the copilot inside the platform. If you need to pull from email, calls and systems outside the CRM, a custom copilot that writes back to Salesforce is usually the better fit. Our Salesforce AI roadmap settles this question in a week.
Where does the copilot get its information?
From sources you already own: CRM records, shared mailboxes, calendar, call transcripts and your product and pricing documents. Access respects each rep's permissions, so nobody sees an account they could not open in the CRM.
How do you stop it inventing account facts?
Every statement in a brief is tied to a retrieved source, shown inline. Claims without a source are not written. We test this on your real accounts with an eval set before any rep sees it, following the approach in evaluating LLM outputs.
What does it cost to run?
Most of the cost is per-request model usage, which depends on how much context each brief needs. Use the LLM cost calculator with your rep count and daily meeting volume for a first estimate.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.