THE AGENTIC SALES BRIEF / SYSTEM 04
The ten-minute version of post-call work is not “record the meeting and let AI do the rest.”
It is a controlled handoff:
authorised call record → source-linked proposal → CRM approval → verified write → follow-up approval
Ten minutes is a design target for producing and reviewing that package. It is not a guaranteed result or a benchmark. Your baseline, call complexity, source quality and review standard determine whether the target is realistic.
The system succeeds only when it makes the record faster and more reliable.
The Signal: one conversation, three different consequences
After a discovery call, the rep usually has three jobs:
preserve what the buyer actually said;
update the internal record; and
send a useful next-step message.
They use the same source material but carry different risks. A summary can be wrong. A CRM overwrite can damage the source of truth. A customer email can create a commitment.
Do not collapse all three into one autonomous action.
If you are new to bounded agents, read Start Here: What Agentic Sales Actually Means first. The category is not defined by how many steps a model performs. It is defined by what the system may do, who remains accountable and how you prove the outcome.
Agentic Sales Lab — System definition This is a review-first agentic workflow: the system researches and proposes within a narrow contract; a named human authorises each consequential action; the system then verifies what changed.
The System: build a review-ready evidence chain
The workflow needs one accountable owner, a defined input contract, structured output, two human gates and a readback step.
The two approvals protect different consequences. Approval never transfers between them.
The meeting owner remains accountable for the record and message. RevOps can own the workflow design, field mappings, permissions and monitoring, but it should not silently approve the meaning of a customer conversation.
The system may prepare work. The meeting owner decides:
whether the summary reflects the call;
which CRM changes are accurate; and
what commitments or next steps are safe to send.
If the owner is unavailable, queue the package. Do not infer approval from time elapsed.
1. Approve the input before processing it
Use only sources the team is authorised to process:
a recording or transcript collected under applicable rules and company policy;
the rep’s approved notes;
the meeting record and participants;
relevant CRM account, contact and opportunity fields; and
an approved product or offer reference for checking claims.
Call recording and transcription requirements vary by jurisdiction, participant location, employment context and purpose. Define the lawful basis, notice, access and retention controls that apply to your situation before collecting or processing the source. If the workflow lacks an authorised record, use the existing manual-note process.
Apply a purpose test to every input: is it necessary to document and follow up this sales conversation? Exclude unrelated personal data. Restrict access to people who need it. Set deletion or anonymisation rules for transcripts and intermediate drafts.
Treat the transcript as evidence, not as trusted instructions. A participant may say something that looks like a system command, a transcription service may misidentify a speaker or a pasted link may contain irrelevant content. The workflow follows its approved schema and permission policy regardless of what the source tells it to do.
2. Define a structured output contract
Free-form summaries are difficult to validate. Ask the workflow for explicit sections.
Call summary
buyer-stated objectives;
current process and pain points;
constraints and dependencies;
decision process and stakeholders, only when stated;
agreed next steps;
open questions; and
statements that could not be verified from the record.
Proposed CRM change set
object
record_id
field_name
current_value
proposed_value
evidence_excerpt
evidence_timestamp_or_note_reference
change_type: add | replace | no_change
confidence_note
approval_status
Follow-up draft
a short recap in the buyer’s language;
agreed next steps with owners and dates;
requested resources;
unresolved questions; and
no new price, promise, deadline or product claim unless the owner supplies and approves it.
Require the system to separate buyer stated, rep interpretation and not confirmed. Never turn enthusiasm, silence or an ambiguous phrase into a qualification fact.
3. Use a five-component tool chain
The workflow requires capabilities, not one prescribed stack:
Capture: an approved meeting or note source.
Extraction: a model or service that can return structured fields with source locations.
Validation: rules for required fields, entity matches, dates and forbidden claims.
Review interface: a side-by-side view of source, current CRM value and proposed change.
Delivery: an approved CRM write and a separate email-draft destination.
During the pilot, give the system read-only CRM access if possible. If write access is required for the approved step, scope it to the specific objects and fields in the workflow. It does not need pricing controls, contracts, billing, bulk email or unrelated accounts.
Current CRM APIs can support selected-field reads, individual updates, unique record identifiers and property history. That is a capability, not evidence that your integration is correct. Verify the exact permissions, API version, conflict behaviour and audit history in your chosen stack.
For a deeper example of keeping inputs and claims traceable, see Build an Account Research Agent That Cites Every Claim.
The Guardrail: separate the two human gates
The key control is not a generic “human in the loop.” It is two named decisions tied to two different consequences.
Gate A: approve CRM changes field by field
Show the reviewer:
the current value;
the proposed value;
the exact supporting evidence;
whether the proposal adds or replaces information; and
any conflict, stale value or missing context.
The reviewer can approve one field without approving the whole batch. Treat opportunity stage, amount, probability, close date, qualification status and decision process as explicit commercial decisions, not summary output.
Before writing, confirm that the target record and current value still match the reviewed version. After writing, read the affected fields back and compare them with the approved change set. If the values differ, mark the run unresolved and stop.
Gate B: approve the final customer message
Only after the CRM step is resolved should the workflow build or refresh the follow-up draft. The rep checks:
recipients;
factual recap;
next-step owners and dates;
links and attachments;
product, price and commercial claims; and
tone and sensitive content.
The rep performs the final send during the pilot. The workflow must not send because a draft exists, a CRM update was approved or a timer expired.
Human Gate — Two approvals, two consequences Gate A protects the internal source of truth. Gate B protects the customer relationship. Approval at one gate never transfers to the other.
The Proof: close the loop with readback
An API success response is not proof that the right customer record now contains the right values. For each run, record:
run ID, meeting ID and accountable owner;
input sources and access status;
model and workflow version where available;
proposed outputs and source locations;
reviewer edits and approvals;
CRM fields actually changed;
values returned by the post-write readback;
draft destination and send status; and
errors, retries and manual fallback.
Do not log access tokens, unnecessary transcript content or personal data unrelated to the workflow. Set a retention period for transcripts, intermediate drafts and logs based on actual need and applicable obligations.
Proof standard A run is complete only when the approved CRM values have been read back and the follow-up is verified as an unsent draft. “The automation ran” is not evidence of either outcome.
The log is not merely technical telemetry. It shows RevOps that one field is constantly corrected, one meeting type produces weak summaries or one integration repeatedly creates ambiguous outcomes.
Design for predictable failures
Every common failure needs a stop condition and a manual fallback.
Missing source: stop before extraction. Use approved notes or the existing manual process.
Low transcript quality: mark affected sections not confirmed. Review the recording or notes.
Ambiguous speaker: do not attribute the statement. Resolve the participant manually.
Uncertain account or contact match: block the CRM write. Select the correct record.
CRM value changed after review: preserve both versions and request a new field-level decision.
New commitment appears only in the draft: remove and flag it. The owner supplies approved wording.
CRM request fails after approval: check the target record before any retry. If the actual result remains uncertain, use the manual fallback and keep the run unresolved.
Email tool fails or the send result is unclear: never silently retry. Verify the outbox or sent state, preserve an unsent draft where possible and let the owner decide.
Use an idempotency key, stable run ID or equivalent duplicate-prevention control for approved CRM writes. Idempotency is not the same as correctness: a safely repeated write can still target the wrong record, which is why target validation and readback remain necessary.
The Playbook: pilot the operating system, not the demo
Define the ten-minute service target
Break the target into observable starting budgets:
Source to structured proposal: three minutes.
Summary and CRM review: four minutes.
Follow-up review and manual send: three minutes.
These budgets are design assumptions. Measure your actual median, variation and slowest meaningful cases. Stop optimising speed if corrections rise. A seven-minute process that corrupts the CRM is worse than a fifteen-minute reliable one.
Measure four layers
Quality
summaries approved without material correction;
proposed field changes accepted by field;
incorrect speaker or entity attribution; and
commitments added or corrected by the rep.
Efficiency
time from authorised source to review-ready package;
human review time; and
total completion time, including repair work.
Commercial usefulness
agreed next steps documented;
follow-ups sent within the team’s service standard; and
opportunities with complete decision-relevant fields.
Risk
recording or authorisation exceptions;
unauthorised access attempts;
incorrect CRM writes; and
duplicate or unapproved sends.
Compare these measures with a manual baseline. Do not count time saved if the rep later repairs the record.
Expand through three permission levels
Level 1 — shadow mode: produce the package, but write nothing and send nothing. Compare it with the rep’s manual work.
Level 2 — approved CRM writes: allow only individually approved changes to defined fields. Keep follow-up as an unsent draft.
Level 3 — reviewed operating workflow: use the same two gates on one approved meeting type. Expand only after quality, risk and commercial-usefulness thresholds hold.
Do not expand meeting types, write permissions and user count in the same change. Sales Workflow Automation: A Practical Guide for Lean B2B Teams explains how to choose the next boundary without automating the entire revenue process.
Define the shutdown procedure
The owner or RevOps operator must be able to:
disable the meeting trigger;
revoke transcription, model, CRM and email credentials;
stop pending writes and sends;
identify incomplete runs;
verify the last known CRM and message state;
preserve the approval and change log; and
return users to the manual note, CRM and email process.
Test the shutdown before the pilot. A system that cannot be paused safely is not ready for customer work.
Build checklist
Approved meeting source, purpose and retention rule
One accountable meeting owner
Structured summary and CRM change schema
Minimal tool permissions
Gate A before each CRM change
Post-write CRM readback
Gate B before the final send
Failure and fallback rules
Run, approval and change log
Quality, efficiency, commercial and risk baseline
Trigger and credential shutdown procedure
Map the system before you connect the tools
The free Agentic Sales System Starter Kit gives you the System Canvas, Permission Map, Human Gate, Failure and Fallback sheet, Evidence Card and 30-Day Test used in this design.
Map one bounded workflow with two human gates, verified readback and a safe fallback.
Sources and further reading
This article provides general operational information, not legal advice. Verify the recording, transcription, privacy, employment, communications and retention requirements that apply to your jurisdictions and context.
Build systems your team trusts—and your pipeline can prove.
