#The challenge
A small full-cycle sales team was carrying the whole post-call burden by hand: re-typing what was said into CRM fields, writing the follow-up email, and remembering what the previous call on the same opportunity had established. The call-recording tool could generate notes and attach them to records, but it could not evaluate the company's own qualification criteria and could not write values into specific fields. The leadership ask was explicit and constraining from the first session: whatever gets built must keep a human in the loop, and it must not be so fiddly to operate that reps stop using it.
#The approach
Put an orchestration layer between the recorder and the CRM
The call-recording tool fires a webhook when a transcript completes. A workflow-automation platform is the infrastructural layer: it receives that event, pulls the transcript back, runs the analysis, proposes the field updates and the email draft, and handles all interaction through a custom chat app. The recorder does what it is good at, the CRM stays the system of record, and the reasoning and the human gate live in between. Per-rep configuration stays on the recorder side, where meetings can already be filtered by domain, internal-versus-external, or keyword.
Constrain the field surface deliberately
The agent writes to an explicit, enumerated list of roughly twenty opportunity fields — the qualification criteria the business actually runs on — rather than being handed the object. The alternative was considered and rejected: connecting the agent straight to a CRM tool server would let it reach any field, and in testing that behaviour produced attempts to write picklist values that did not exist in the org. Rigid is the point. A separate static reference table holds the criteria, rules and thresholds as a data dictionary the agent reads at run time, so tuning what 'qualified' means is a data edit rather than a prompt rewrite.
Write the prompt as a set of precedence rules, not a description
The extraction agent runs on stated rules: blank fields are prioritised; populated fields are only changed if the transcript adds genuinely new or contradictory information; output must conform to a fixed format. Structured output parsers sit on each agent with an explicit schema declaring which CRM fields are expected and their types. Nulls are handled as a first-class case — anything the model returns empty is mapped to undefined rather than to an empty string, because otherwise the CRM interprets it as an instruction to blank the field.
Make chat the interface, and make it revisable
The proposed updates post into chat showing the current value beside the proposed one. The rep can approve in a sentence, or push back in plain language and get a revised proposal, looping as many times as needed inside a bounded conversation context. The bot only responds when mentioned rather than watching the whole channel, so it does not become noise. Nothing writes until the rep approves. The design point is that the rep never has to open the CRM to do CRM work, but the CRM never changes without them.
Solve the missing-history problem with a snapshot object
The CRM caps how many fields can have native history tracking, which is fewer than the qualification model needs. A custom object stores a snapshot record per pipeline run, carrying the prior values and a long-text field for the transcript itself. That gives the agent real previous-call context to reason against on the next call, and gives the business a progression record the platform would otherwise not keep.
Draft the follow-up email, and never send it
A parallel branch generates the follow-up email in the tone the rep used on the call, writes it to a document, and sends the rep a direct message with a link to the draft and a link back to the recording. It does not send, does not post, and does not touch the CRM. The recipient logic was changed mid-build from the meeting host to the opportunity owner, because in a small team the person on the call is often not the person who owns the deal.
Choose the cheapest model that clears the bar, and configure a fallback
The whole pipeline runs on the smallest model in the family — roughly a fifth the cost per interaction of the mid-tier model — because the task is structured extraction against an explicit schema, not open-ended reasoning. A fallback model is configured in the workflow after a provider incident took the primary one down mid-build. At a couple of dozen calls a week across the team, the running cost was small enough that it stopped being an objection.
Let the agent read the CRM's own validation rules instead of duplicating them
For record creation, validation fires before insert regardless of what the agent proposes, so the rules cannot be bypassed. Going through the API gives more than the UI does: rather than surfacing one missing field, then the next, then the next, the agent can enumerate everything that has a dependency and ask for it all at once. The opportunity-progression logic and required-fields-by-stage rules live in a markdown context document the agent reads as a tool — kept in a version-controlled repository rather than a wiki, for latency.
Ship it as a governed toolset, not as individual reps' scripts
Rather than each person building and trading their own assistant configurations, a standardised repository with a private marketplace distributes plugins and skills, with a single update command for reps. Governance is explicit: no rep-built skill ships to the marketplace, and maturity runs beta with one volunteer, then general availability, then quarterly maintenance review. Brand voice, facts and competitor policy live in one shared context plugin and are never inlined into individual skills, so they can be changed in one place.
State the write permissions on the face of every skill
Each rep-facing skill is labelled read-only, creates-a-draft, or writes-but-asks-first, with a plain-language guarantee: nothing is sent, posted or saved to the CRM on your behalf without you seeing it first. Field changes are shown as current value, then recommended value, then the reason from the call. One skill writes a local revert log capturing prior values before a recommended change. This labelling did more for adoption than any capability did.
Give the team one place to ask for the next thing
A shared help-desk channel replaced an ad-hoc request path, with a submit-a-request workflow, weekly triage, and accepted requests scoped into the build queue. The stated posture was that you do not need a fully formed idea, and that deciding whether the answer is a skill, an automation or a five-minute walkthrough is the operator's job, not the requester's.
Pressure-test the architecture against the simpler alternative, in public
Midway through, the customer asked directly whether the complexity was worth it versus just running scheduled daily tasks that produce recommended follow-ups and CRM updates at end of day. That question got answered on its merits — the event-driven path exists to cut latency and to carry cross-call context, at a consumption cost — rather than deflected. A build that cannot survive that question should not be built.
#Outcomes
The pipeline works end to end and was demoed live
Transcript ingestion, structured extraction, chat-based review with a revision loop, and programmatic write-back to the opportunity plus creation of the snapshot record all ran in a demo against pinned data. The email-draft branch produced a document and a direct message in the same run.
The governed skill layer is live with reps
A repository, private marketplace, plugins and a documented skill set across sales, sales leadership, revenue operations and marketing shipped, each with an explicit permission label and a reference page. Opportunity creation and update run as a hybrid: reps can work through chat or stay in the CRM, and validation enforces the same rules either way.
Deployment into the customer's environment hit authentication blockers
The pipeline was built and tested on the delivery team's own systems and then moved into the customer's environment, where a connected-app authentication issue in the CRM sandbox and a missing integration node in the automation platform blocked it. Those were worked through, but at the latest evidence there is no record of a real customer sales call flowing through the pipeline and writing to their production CRM.
Several scoped pieces stayed scoped
A unified customer-context layer spanning CRM, email and transcripts, the AI email drafting built on top of it, and the data-access and permissions model that gates both, were all defined as work items and never designed or decided. The organisation-wide enablement rollout has no record of running, and the help-desk channel shows no customer-submitted requests. That gap between what was built and what was adopted is the honest headline.