After a sales call, a small team faces a predictable trail of work: write notes, update the CRM, draft the follow-up, involve a specialist, record objections and schedule the next step.
An AI agent can appear to solve all of it. Give the model a transcript and access to the tools, then ask it to “handle the follow-up.” That makes a compelling demonstration and a fragile operating design.
Make's 2026 description of its internal Post-Call Hero offers a more useful pattern. The company says the system consists of seven classic automations, three AI automations and one agentic process. Suggested CRM changes remain subject to human approval.
The agent is not the system. It is one bounded decision layer inside the system.
Evidence note
Make reports that Post-Call Hero released four hours per representative per week and contributed to a 32% increase in sales revenue. These are company-published internal results, not an independent evaluation. “Contributed to” should not be rewritten as “caused.”
The architectural detail is more transferable than the headline metric.
Divide the workflow by type of work
Deterministic automation moves and checks
Use ordinary software for steps with a known rule:
- detect that a call has ended;
- retrieve the transcript;
- identify the account and opportunity;
- validate required fields;
- compare dates and identifiers;
- create a task from approved data;
- write an approved value to the CRM;
- send a message through an authenticated service;
- record success or failure.
These steps should behave the same way for the same input.
AI transforms ambiguous language
Use a model where the input is unstructured and judgement helps:
- summarise the conversation;
- extract customer goals and constraints;
- classify objections;
- draft a follow-up;
- identify a possible product gap;
- suggest which CRM fields may need updating.
The output should be structured and linked to the source transcript where practical.
An agent chooses among bounded tools
An agent is useful when the system must choose a path based on context. For example:
- if a technical question is unresolved, propose involving a solutions specialist;
- if legal review is requested, route to the approved legal workflow;
- if the next step is clear, prepare the corresponding task;
- if evidence is weak, ask for human clarification.
Give the agent a small toolset and explicit stop conditions. “Access to the entire workspace” is not a capability design.
A person owns the consequence
For customer communication, commercial commitments and material CRM changes, a person should see:
- the proposed action;
- the source evidence;
- what changed;
- any uncertainty or missing field;
- an approve, edit or reject choice.
Approval should take seconds because the evidence is present, not minutes because the employee must reconstruct the call.
The 7 + 3 + 1 architecture
The exact count will differ in another company. The ratio makes a point: most of the system can remain observable and deterministic.
Design the process from the record backwards
Start with the CRM record you want after the call:
- account and opportunity;
- confirmed need;
- decision criteria;
- stakeholders;
- objections;
- agreed next step and date;
- open technical or commercial question;
- follow-up status;
- source call and transcript.
For each field, define:
- whether the transcript can support it;
- whether AI may propose it;
- what validation applies;
- who may approve it;
- whether an absent value stays blank or triggers a question.
Do not reward the model for filling every field. An explicit “not stated” is better than a plausible invention.
A reliable post-call sequence
1. Capture
Receive the transcript and call metadata from an authorised source. Verify meeting, participants, language and consent requirements for recording and transcription.
2. Resolve identity
Match the call to the correct account, contact and opportunity. Use stable identifiers. If two records are plausible, stop for human selection.
3. Extract with evidence
Ask the model for a structured result, for example:
- customer objective;
- current constraint;
- decision date;
- objection category;
- requested follow-up;
- quoted or timestamped support.
Schema validation catches missing or malformed fields. It does not prove the interpretation is correct, so retain evidence for important claims.
4. Apply business rules
Check deterministic conditions:
- the date is valid;
- the owner exists;
- the opportunity stage transition is allowed;
- a discount is within authority;
- required consent is present;
- restricted commitments are absent;
- no duplicate task already exists.
5. Draft actions
Generate the follow-up email, CRM diff, tasks and specialist-routing suggestion. Keep them as proposals.
6. Review at one control point
Present a compact bundle:
- call summary;
- proposed email;
- CRM fields before and after;
- new tasks;
- escalations;
- evidence links.
Allow selective approval. A representative may accept the notes but edit the email and reject one CRM change.
7. Execute deterministically
After approval, use normal APIs to update the CRM, create tasks and send messages. Do not ask the language model to simulate success. Read the response from the system and record the identifier.
8. Audit and learn
Capture edits and rejection reasons:
- wrong account;
- unsupported inference;
- missed commitment;
- wrong tone;
- duplicate action;
- bad routing;
- policy violation.
Recurring defects should change the data, prompt, rule or workflow. They should not become an endless instruction appended to one giant prompt.
Controls that matter for a small sales team
Least-privilege tools
Separate read, propose and write capabilities. An early version may read transcripts and draft changes without permission to send or modify records.
Explicit customer-commitment boundary
Create a rule for promises involving price, delivery, contract, security, legal interpretation or custom product work. Route these to the authorised owner.
Idempotency and duplicate prevention
Retries happen. Use stable call and action identifiers so a failed response does not create two tasks or send two follow-ups.
Source-linked output
For key extracted facts, include the timestamp or transcript passage that supports the proposal. This shortens review and discourages confident invention.
Observable failure
Do not hide a failed CRM update behind a green “completed” message. Surface the exact failed step, preserve approved work and provide a safe retry.
Manual fallback
The representative must be able to complete follow-up when the AI layer is unavailable. Automation should reduce work, not hold the customer relationship hostage.
Metrics that separate activity from value
Track a balanced set.
Efficiency
- active post-call minutes;
- elapsed time to follow-up;
- percentage of calls processed;
- reviewer time.
Quality
- accepted without edit;
- accepted with edit;
- rejected;
- serious factual error rate;
- duplicate or failed action rate.
Sales process
- CRM completeness;
- follow-up sent within target time;
- next step with owner and date;
- specialist-response time;
- opportunity progression.
Commercial outcome
- win rate and sales-cycle duration;
- contribution margin;
- expansion and retention where relevant.
Do not attribute revenue movement to the automation without controlling for territory, demand, staffing, pricing and pipeline mix.
A two-week pilot
Days 1–3: Baseline
Measure 20 recent calls. Record active work, follow-up delay, missing fields and correction patterns.
Days 4–7: Shadow output
Generate notes, drafts and CRM proposals without writing anything. Compare with the representative's actual follow-up.
Days 8–10: Human-approved live actions
Enable one-click approved CRM updates and drafts for a small group. Keep email sending manual at first.
Days 11–14: Review defects
Classify every edit and failure. Expand only if serious errors are rare, review effort is lower than the work removed, and the team trusts the evidence.
Why this pattern fits the European context
The European Commission's 2026 agentic-AI report highlights traceability, meaningful human oversight and auditable control points as important conditions for safe scaling. A workflow-first design supports those properties without preventing useful automation.
It also makes supplier changes easier. Transcription, language transformation, orchestration and CRM action remain separable components instead of one opaque agent.
The practical rule
Use deterministic automation for what must be exact. Use AI for what must interpret language. Use an agent only where choosing among a small set of tools creates value. Keep a person at the boundary of consequential action until evidence justifies a different design.
That is less theatrical than an autonomous agent — and much closer to a system a small business can operate.
References
- Make. “How to scale AI with Make: Build foundations first.” 17 February 2026. Company-published case (opens in a new tab).
- European Commission. “Agentic AI: Leveraging European AI talent and Regulatory Assets to Scale Adoption.” 23 January 2026. Report (opens in a new tab).
Put the controls into practice
Use Value Stream Mapping to model the complete post-call flow, Mistake Proofing to protect the action boundary, FMEA to test failure modes, and PDCA/PDSA to release the workflow in a bounded pilot.