After-call work is the silent drain on every contact centre's capacity. When a call ends, the agent does not move to the next caller. They spend the next 60 to 90 seconds -- sometimes two minutes or more -- wrapping up: logging a disposition code, updating the CRM record, scheduling a follow-up task, or flagging the interaction for quality review. Across a team of 50 agents handling 200 calls a day each, that is more than 150 agent-hours lost to administrative work before anyone speaks to a customer again. At 25 to 30 pounds per agent-hour fully loaded, the cost is material enough to appear on a P&L.
Enterprise voice AI eliminates that layer entirely. When the AI agent handles the call, the same system that ran the conversation also produces a clean transcript, a classified intent, an extracted entity set, and a set of follow-up actions -- all before the interaction closes. There is no wrap-up delay, no disposition field left blank, no CRM record updated three calls later from memory. The output is a coded, actioned, audit-ready record written the moment the call ends.
This post covers the architecture behind AI-driven after-call work: how disposition coding works, how CRM write-back should be designed to protect data integrity, how follow-up tasks are triggered without human action, and what the compliance picture looks like when a machine codes every interaction. It is the operational layer that most enterprise voice AI programmes design last -- which is exactly why it should be designed first.
This guide is written by the team behind Dilr Voice -- enterprise voice AI handling calls in 40+ countries. For the broader operating model around voice AI programmes, see DILR.AI's AI Operating Model service, or the complete enterprise voice AI guide.
According to McKinsey's State of AI 2025, 88% of enterprises now use AI in some form, but only 33% have deployed it into production workflows. After-call work automation is one of the highest-ROI contact centre automation targets precisely because it requires no change to the customer experience. The caller has already hung up. Every saving is pure operational gain.
What Is After-Call Work, and Why Does It Cost Contact Centres So Much?
After-call work (ACW) is the administrative period between when a call ends and when an agent becomes available to take the next call. Industry benchmarks place typical ACW at 60 to 90 seconds per interaction in well-run contact centres, rising to three or four minutes in teams with poor tooling, fragmented CRM systems, or complex disposition taxonomies. In regulated industries such as financial services, healthcare, and housing associations, the wrap-up includes mandatory fields, compliance notes, and next-action scheduling that agents cannot shortcut.
The cost components of ACW stack quickly:
None of these costs are invisible. They show up in Average Handle Time (AHT), in first-call resolution rates, in complaint coding accuracy, and in the headcount required to hit service-level agreements. The contact centre operations director who pulls apart the AHT metric typically finds that ACW accounts for 25 to 35% of total handle time -- and that it is the component most amenable to elimination.
Which After-Call Tasks Can Voice AI Automate End-to-End?
When an AI voice agent handles a call, the same system that ran the conversation is also able to produce the complete ACW output immediately, without human action. Five categories of after-call task can be fully automated.
Disposition coding. The call transcript is classified against the contact centre's disposition taxonomy: resolved, escalated, unresolved, callback required, complaint, payment arranged, and so on. A well-designed disposition taxonomy maps cleanly to the intent signals in the conversation, and the AI classification is available within two to three seconds of hang-up.
CRM record update. Every entity captured during the call -- account number, postcode, issue description, appointment date, amount agreed -- is written to the customer's CRM record with a structured interaction note. No agent types a summary. No field is left blank because the agent moved to the next call without finishing.
Follow-up task creation. If the call requires a follow-up action -- a callback, a support ticket, an email confirmation, a case update -- the AI triggers the appropriate downstream system tool call immediately after the call closes. See the tool-calling architecture that enables this at voice AI tool calling: enterprise architecture that ships.
Escalation routing. Calls that met escalation criteria during the conversation (complaint language detected, distress signals identified, regulatory sensitivity flags triggered) are routed to the QA review queue or supervisor inbox automatically. The escalation reason, the transcript excerpt that triggered it, and the sentiment arc are pre-populated. For the human handover design pattern, see AI voice escalation: designing human handover that works.
Call summary generation. A structured summary -- written for the next agent or AI agent that interacts with this customer -- is generated from the transcript and stored against the customer record. This is the foundation of the cross-call memory layer described at voice AI RAG: knowledge bases that work on live calls.
When a human agent handled the call (with AI in the QA or assist layer), the same transcript is available within seconds of hang-up. In a human-assist model, the AI drafts the disposition code, CRM note, and follow-up action for the agent to review and confirm in a single click -- reducing ACW from 75 seconds to 10 to 15 seconds, rather than eliminating it entirely.
What Is the Architecture That Turns a Call Into a Coded, Actioned Record?
The ACW automation pipeline runs in six steps, each building on the output of the previous one.
Step 1: Real-time transcription. From the moment the call begins, the voice stream is transcribed with speaker labels, timestamps, and utterance boundaries. By the time the call ends, the full structured transcript is already available for processing. This is the foundational data layer -- without it, none of the downstream steps are possible. For the transcription architecture, see real-time transcription AI voice: enterprise data layer.
Step 2: Intent and entity extraction. A lightweight classification model reads the transcript and identifies the primary call intent, sub-intent, entities captured (account number, postcode, issue description, amounts, dates), the sentiment arc across the call, and escalation triggers (complaint language, distress signals, requests for a supervisor). See how sentiment extraction works across a voice programme at AI voice sentiment analysis: what enterprises measure.
Step 3: Disposition classification. The extracted intent is mapped to the contact centre's disposition taxonomy. For taxonomies with fewer than 50 codes, direct classification is sufficient. For larger taxonomies, embedding-similarity lookup against a vector store of labelled examples produces better coverage on edge cases. The classification is scored with a confidence value, and the top-three alternative codes are stored alongside the primary code in the audit log.
Step 4: CRM write-back. The disposition code, entities, interaction summary, sentiment flag, recording reference, and confidence score are written to the CRM via API call or webhook. The write-back is idempotent: a unique call ID written to the interaction record before the write attempt prevents duplicates if the system retries. For the full integration architecture, see voice AI CRM integration: the architecture that ships.
Step 5: Tool calling for follow-up actions. If the call outcome requires downstream action, the appropriate tool call fires immediately. The tool definitions available to the post-call layer are the same ones available during the call: calendar API for callbacks, ticketing system webhook for support cases, SMS gateway for confirmations, QA queue for review routing. For the tool-calling design, see voice AI tool calling: enterprise architecture that ships.
Step 6: Audit log entry. Every step is written to an immutable audit log: transcript hash, transcription model version, classification model version, disposition code assigned, confidence score, alternative codes scored, entities extracted, CRM fields written, follow-up actions triggered with response status codes. This is the audit trail regulators and procurement teams expect to see on request.
The pipeline runs in two to four seconds after hang-up. The agent or system is available for the next call before the audit log entry is complete.
How Does AI Disposition Coding Compare to Human Agents in Accuracy?
The comparison is not binary, because human disposition coding varies enormously by team, training quality, and CRM usability. When enterprises run AI coding in parallel with human coding for calibration, four patterns consistently emerge.
Consistency. AI applies the same taxonomy mapping rule on every call. Human agents calibrate inconsistently, particularly on boundary cases where two or more codes could plausibly apply. When disposition data feeds downstream analytics -- identifying repeat contact drivers, measuring first-call resolution, flagging complaint clusters -- consistent AI coding produces cleaner signal than human coding sampled at 3 to 5% of volume.
Coverage. AI codes 100% of calls. Human quality assurance typically reviews 3 to 5% of interactions. The AI-coded dataset is complete; the human-reviewed sample is not. Any pattern that appears in only 2% of calls is invisible to human QA but visible to AI coding at full volume.
Latency. AI coding completes within two to four seconds of hang-up. Human coding completes 60 to 90 seconds after hang-up, with accuracy degrading for interactions coded retrospectively more than a few minutes after the fact.
Edge cases. AI classification confidence degrades on calls with high transcription error rates (heavy accents, background noise, poor audio quality), calls with ambiguous intent where the caller never stated a clear outcome, and calls where partial information was exchanged and no clean resolution was reached. These are the cases where human review adds the most value.
The correct design is not binary. AI codes every call. A confidence threshold -- typically set at the 80th percentile of the classification score distribution -- flags a subset of interactions for human review. Quality assurance resources are concentrated on the flagged calls rather than spread across a random sample. The result is better coverage at lower cost, with human judgment applied where it adds the most marginal value.
For the testing and sampling framework that integrates with this approach, see AI voice agent QA and testing: an enterprise framework.
How Should CRM Write-Back Be Designed to Protect Data Integrity?
CRM write-back is where ACW automation most commonly breaks in production. The failure modes are predictable, and designing against them upfront is far cheaper than fixing them after a data quality incident.
Overwriting existing data. If the AI write-back overwrites the entire customer record rather than appending a new interaction record, previous context is destroyed. The correct design always writes to a new interaction record. Static customer fields -- name, address, account preferences -- are only updated when the call explicitly produced a verified change to those fields.
Missing mandatory fields. If entity extraction fails on a field that is mandatory in the CRM schema, the write-back must not silently submit an incomplete record. The correct design flags the gap in the audit log, writes what it has, and surfaces the missing field in the human review queue for completion.
Duplicate records. Telephony retries and webhook delivery failures can cause the post-call pipeline to run twice for a single call. Idempotency keys -- a unique call ID written to the interaction record as the first step of the write-back -- prevent duplicate records. The write-back checks for an existing record with the same call ID before writing.
Schema drift. CRM field names change when administrators update configuration. The mapping layer between AI output and CRM schema should be versioned, monitored, and tested automatically. A broken field mapping fails silently unless the audit log checks for non-2xx responses from the CRM API and alerts on failures.
Purpose limitation. Not every data point extracted from a call should be written to the CRM. If a caller disclosed a health condition that was not solicited and is not relevant to the service interaction, writing that disclosure to a general-purpose CRM field is a purpose-limitation breach under GDPR Article 5(1)(b). The extraction pipeline should include a data-minimisation filter that identifies and strips personal disclosures outside the programme's declared data processing purpose before the write-back step executes.
For the full integration architecture, including webhook design, field-mapping versioning, and the data-minimisation layer, see voice AI CRM integration: the architecture that ships.
What Follow-Up Tasks Can Be Automated Without Human Action?
The follow-up task layer is where ACW automation moves from administrative convenience to operational capability. Each of the following can be triggered immediately, without human action, as soon as the post-call pipeline completes.
Callback scheduling. If the call ended with a commitment to call back within a defined window, the AI creates a scheduled outbound call task with: correct queue assignment, the caller's verified number, the call summary as context for whoever handles the callback, and a time window respecting PECR calling-hours restrictions. The callback is visible in the contact centre queue within seconds of the original call ending.
Support ticket creation. If the call identified an unresolved issue requiring backend action -- an engineer visit, a billing correction, an account change, a policy update -- the AI creates a support ticket in the ITSM or CRM system with: issue type, priority level, call transcript reference, entities extracted, and a structured description generated from the call summary. The ticket is created with the correct priority before the caller has reached their car.
SMS confirmation. If the call produced an agreement, appointment, or payment arrangement, the AI triggers an SMS confirmation within seconds of hang-up. The message content is generated from the structured call output: appointment date, reference number, confirmation code, next steps. Consent for SMS contact should have been captured during the call or must already be on file from a prior interaction.
QA escalation. Calls that met escalation criteria during the conversation are added to the QA review queue automatically, with the transcript, sentiment arc, escalation reason, and relevant timestamps pre-populated. The QA reviewer opens a pre-built case rather than building context from scratch. For the handover design that bridges AI handling and QA review, see AI voice escalation: designing human handover that works.
Case status update. If the call was a follow-up to an existing open case, the AI identifies the case reference (extracted from the conversation or matched from the CRM lookup during the call), updates the case status, adds the interaction note, and adjusts the SLA clock based on the call outcome.
Cross-call context persistence. The structured call summary is stored against the customer record in a format that the next AI agent can retrieve at the opening of the next interaction. For the retrieval architecture that enables this, see voice AI RAG: knowledge bases that work on live calls and voice AI warm transfer: the context handoff.
Is AI-Generated Disposition Audit-Ready Under ICO and FCA Frameworks?
This is the question legal and compliance teams ask before approving automated ACW. The answer is yes, if the audit architecture is built correctly from the start.
ICO expectations (under the AI Code of Practice, SI 2026/425, in force May 2026): automated processing decisions should be logged with enough information to explain what was processed and why. The logic used to classify an interaction should be documentable. Organisations should be able to produce call-level records in response to a Subject Access Request, including the disposition coding and all follow-up actions triggered. For the GDPR data obligations that surround voice AI post-call processing, see the DPIA template at voice AI DPIA: the impact assessment template.
FCA expectations (Consumer Duty, AI governance, FCA Code of Conduct extension to AI-assisted communications from September 2026): firms should demonstrate that AI-assisted processes produce outcomes consistent with Consumer Duty obligations. Complaint identification must be reliable and consistent. An AI coding system that misses complaint language, or under-reports complaint codes relative to human coding, creates a Consumer Duty evidence gap. The audit trail must be sufficient for the firm to understand, investigate, and correct poor outcomes at interaction level.
The minimum audit trail for AI disposition coding:
- Call recording reference or transcript hashImmutable identifier
- Transcription model version and confidenceFor error attribution
- Classification model version and confidenceFor disposition traceability
- Disposition code assigned and top-3 alternativesEvidence of classification logic
- CRM fields written (names, values, timestamp)Data lineage
- Follow-up actions triggered with response codesDownstream accountability
- Human review flag, reviewer ID, outcome (if sampled)Override trail
This structure satisfies both ICO Subject Access Request obligations and FCA supervisory expectations. It also satisfies the auditability obligations described in the broader framework at AI voice auditability: building explainability into deployments.
For incident response when ACW automation produces a coding error that propagates through downstream systems, the runbook pattern at voice AI incident response: the runbook for when it breaks applies directly to post-call pipeline failures.
What Does Eliminating After-Call Work Actually Save?
The ROI calculation for ACW automation is among the most direct in the voice AI toolkit, because the saving is linear, verifiable, and appears in the AHT metric within weeks of deployment.
The assumptions: 10,000 calls per day, average ACW of 75 seconds per call at baseline, 28 pounds per agent-hour fully loaded. With 85% of calls fully automated (two-second write-back confirmation latency) and 15% flagged for human review at 20 seconds each, the blended post-automation ACW falls to approximately 13 agent-hours per day. The saving is 195 agent-hours per day -- 5,460 pounds per day, or just under 2 million pounds per year at that volume.
The capacity released by eliminating ACW does not need to disappear. It can be redeployed: higher call volume without headcount increase, reduced hold times, or agents freed for complex conversations that benefit from human attention. That redeployment story is often the one that gets a voice AI business case approved where the cost-cutting story alone would not. For the redeployment business case framing, see building the business case for AI voice automation.
The correct metric to track ACW automation in production is Average Handle Time, specifically the ACW component. Most contact centre telephony and WFM platforms expose ACW as a separate segment in the AHT breakdown. If AHT falls and the ACW segment closes to near-zero, the automation is working. For the full KPI framework that captures ACW alongside containment rate, CSAT delta, and cost per resolved interaction, see KPIs for enterprise AI voice programs. For the full programme ROI model including implementation costs and payback period, see AI voice ROI framework: total programme economics.
Stanford AI Index 2026 notes that fewer than 10% of enterprises have fully scaled AI in any single function. ACW automation is one of the clearest paths to that scaling threshold because it operates entirely in the background, with no customer-facing risk, and produces measurable AHT reduction within the first operational week.
- Disposition taxonomy designed for human judgment, not machine classification. A taxonomy with 200 overlapping codes that trained agents navigate by instinct is not classifiable by an AI without extensive labelling. Design or simplify the taxonomy with clear, mutually exclusive definitions before building the classifier.
- CRM write-back tested in sandbox, not production. Sandbox CRM instances often have different schema versions, rate limits, and permission models than production. Test the write-back against production with a read-only first pass before enabling writes.
- No confidence threshold defined before go-live. Deploying AI coding without a confidence threshold means low-quality classifications go straight to the CRM with no human review. Set a threshold before go-live, calibrate it on the first 10,000 calls, and monitor it weekly.
- Follow-up tool calls not idempotent. If the post-call pipeline retries a failed tool call (callback scheduled, ticket created), duplicates appear in the downstream system. Every tool call in the follow-up layer must be idempotent by design, using a unique call ID as the idempotency key.
- Audit log not linked to the CRM record. An audit log that lives in a separate system without a reference to the CRM interaction ID cannot satisfy an ICO Subject Access Request or an FCA supervisory information request. The call ID must be the shared key across all systems.
- Data minimisation not applied before write-back. Special category data disclosed by callers but not solicited by the programme must be stripped from the extraction output before CRM write-back. Purpose limitation is not optional under GDPR Article 5(1)(b).
Ready to see this in a live programme? Try Dilr Voice with your own call flows, book an AI placement diagnostic to scope the ACW saving in your specific environment, or read the DILR.AI approach to placing AI inside operational contact centre workflows.
What disposition taxonomy depth works best for AI coding?
Simpler taxonomies perform better in the first six months of deployment. A taxonomy with 20 to 40 clearly defined, mutually exclusive disposition codes is classifiable with 85 to 90% accuracy by a well-trained classifier. Taxonomies with 100 or more codes, or codes that require agent judgment to distinguish (such as "partially resolved" versus "resolved with follow-up"), require significantly more labelled data and produce more low-confidence classifications requiring human review. The pragmatic approach is to start with a simplified taxonomy, deploy the classifier, and expand toward more granular codes as the labelled dataset grows through production use.
How long does the post-call pipeline take to run?
The full ACW automation pipeline -- transcription completion, intent and entity extraction, disposition classification, CRM write-back, and follow-up tool calls -- typically completes within two to four seconds of hang-up for a three-minute call. Transcription is available in near-real-time during the call, so the pipeline starts before the call fully ends. CRM write-back API response time is the most variable component: well-configured CRM integrations respond in under 200 milliseconds, while legacy systems with rate limits or complex workflow triggers can add two to five seconds.
Can ACW automation work when human agents handle the call?
Yes, and this is often the first deployment step for programmes that are not yet running fully automated AI voice agents. The AI listens to the human-agent call (or processes the post-call recording), generates the disposition code and CRM note as a draft, and presents it to the agent for one-click confirmation. ACW drops from 75 seconds to 10 to 15 seconds. The same architecture transitions to fully automated ACW when AI agents replace human agents on specific call types, because the pipeline is identical -- the input is a transcript in both cases.
How do you handle calls where the AI cannot classify the disposition with confidence?
Low-confidence classifications are flagged and routed to human review. The human reviewer sees the transcript, the top-three disposition codes with their confidence scores, and the relevant excerpt from the conversation that drove the classification. Reviewing and correcting a low-confidence classification takes 15 to 30 seconds, compared to coding from scratch at 75 seconds. Every correction becomes a labelled training example that improves the classifier on similar calls in future runs -- so the human review queue shrinks over time as the model improves on the specific call patterns of that contact centre.
Is the conversation design layer relevant to after-call work quality?
Directly. Calls with well-designed conversation flows -- clear intent confirmation, structured entity capture, explicit outcome statements -- produce higher-quality transcripts and higher-confidence dispositions. Calls that end ambiguously (caller hangs up mid-conversation, agent gives partial information, outcome is never stated) produce lower-confidence classifications and more human review. The conversation design investment pays off downstream in ACW automation accuracy, not just in caller experience. For the conversation design principles that improve post-call processing quality, see voice AI conversation design: scripting that converts.
Place AI where the P&L moves.
30-minute scoping call. No deck. Confidential. We will tell you whether Dilr Voice fits your call mix -- and where the ACW and AHT saving actually lives in your specific programme.
Written by the Dilr.ai engineering team -- practitioners who ship enterprise AI voice in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.