“Generate notes after sales calls” sounds like an AI project everyone can agree on. It addresses a familiar chore, promises to save time, and produces something useful in a demo. Nobody needs another workshop to understand the appeal of spending less time feeding the CRM goblin.
Try using it on a busy afternoon, though, and a few questions appear. Which call belongs to which opportunity? Who checks the summary? What happens when the customer mentions a possible next step without agreeing to it? Where do corrections go, and who notices if the approved note never reaches the customer record?
Those questions are the operating plan. If the team leaves them unanswered, the first users have to work them out while doing their regular jobs. Let's follow one sales call note through the process and see what needs to be decided.
Start with what finished looks like
A useful call note gives colleagues an accurate account of the conversation, in the correct customer record, with clear responsibility for any agreed follow-up. Generating the summary gets part of that job done. The work is finished when the note has been checked, saved, and made available to the people who need it. A draft in a separate application still leaves someone with work to do, however readable it is.
Name an owner for the overall process, such as the person responsible for sales operations. That person maintains the rules and deals with recurring problems. The salesperson reviews the substance of the call, while whoever maintains the integration handles failed saves. One person may fill several roles on a small team. What matters is that everyone knows who to call when something breaks, instead of assuming the last person who touched the note owns the problem.
Decide what goes into the draft
The workflow starts after a call ends and the source material is ready. That might include an authorized transcript, the salesperson's notes, and a few relevant CRM fields. Show the reviewer which sources were used. Link the call to an opportunity before updating any records, and ask the salesperson to resolve a missing or ambiguous match. Guessing which customer record to update creates a problem that better prose will not fix.
The draft should separate what the customer said, what remains open, and what everyone agreed to do. Suppose a customer says they may bring a colleague to another discussion next week. The note should retain that possibility. It shouldn't turn it into a confirmed meeting or assume the colleague is a decision-maker. Where information is missing, “not established” gives the salesperson something to resolve without inventing an answer for them.
Make the review specific
Put the draft where the salesperson already completes post-call work, with the relevant source material close at hand. Ask them to check customer facts, objections, commitments, owners, and dates. “Check for accuracy” leaves each person to invent a standard. “Confirm that every next step was agreed, with the correct owner and date” tells them what to look for. If the note will support a consequential decision and a quick comparison isn't enough, build time for a fuller review into the process.
For this first version, approval saves the note. Sending a follow-up, changing an opportunity stage, or updating a forecast still requires a separate action. An assistant can suggest those actions, but generating a suggestion doesn't give it permission to act. Keeping the first version focused also makes it easier to see whether the process works before giving it more responsibility.
Show whether the note was saved
The interface should distinguish “draft ready,” “approved,” and “saved to the record.” A cheerful success message after generation is misleading if the CRM has received nothing. The salesperson needs to know whether they're done or whether someone still needs to resolve a failed save.
Keep the connection to the source and approval history so the team can investigate errors. A correction made later needs to reach the record colleagues are reading, along with any follow-up affected by the mistake. Changing a sentence in an abandoned draft won't help them.
Plan for the failures you can already anticipate:
- Missing source material: Explain what's missing and offer the normal manual note process.
- Unclear customer statement: Leave the question open for the salesperson to resolve.
- Incorrect draft: Let the reviewer correct or reject it, and flag recurring problems to the process owner.
- Failed save: Keep the approved work, show that it hasn't reached the record, and assign someone to recover it. Retrying should not create duplicate notes.
You don't need an elaborate system to answer these questions. You do need a way for someone to notice the problem and take responsibility for it.
Remove the old work and test the whole process
Decide what the new workflow replaces. If salespeople still have to write separate call notes and complete the same duplicate report, the team has added a drafting exercise while keeping the original burden. Running both processes briefly can help validate the new one. Give that comparison an owner and a clear stopping point so it doesn't become permanent extra work.
Then measure the work from the end of the call to a usable record. Include review time, corrections, failed saves, and later repairs. Check whether important customer statements survive and whether colleagues can use the final note. A fast first draft matters, but the time saved has to survive the rest of the process.
This also makes it easier to decide when an experiment needs changing. Repeated factual errors might call for a narrower task or a different approach. Failed saves might point to an integration problem. If nobody trusts the result, ask where that trust is breaking down before asking them to try harder to use it.
For the next AI planning session, pick one ordinary call and follow its note all the way into the customer record. Agree on who reviews it, what happens when something goes wrong, and which old task goes away. That's how a promising demo becomes something the team can use on a normal Tuesday.