Building an AI-assisted sales-call review workflow
At HCL GUVI, I was the main author of DORA’s call-quality module. It checks short calls marked “Not Interested” against topic-specific sales guidelines, rejects findings without matching transcript evidence, and sends flagged calls to managers for a final decision. According to the project’s October 2026 production records, it audited more than 20,000 calls; about 6,000 leads were reassigned after manager review. A flag is a review signal, not a confirmed failure. My work included delayed-transcript handling, retryable CRM handoffs and a 210-call replay harness.
How the call-review workflow fits together
- CRM events
- Wait for transcript
- Topic-specific evaluation
- Validate evidence
- Manager decision
- Retryable handoff
The problem: a short call could end a useful conversation
Sales leads marked “Not Interested” after a short call needed a second look. A recording alone does not show whether the salesperson followed the right process, and reviewing every call by hand was a separate operational task. The goal was to identify calls that deserved a manager’s attention and give that manager evidence to make a decision.
I was the main author of the call-quality module inside DORA, a shared internal CRM at HCL GUVI. This case study covers that module and its handoff workflow, rather than claiming ownership of the entire CRM.
Grounding findings in the actual transcript
The workflow qualifies calls under two minutes on leads marked “Not Interested”. It waits for a transcript before evaluating; the presence of a recording is not enough. The evaluator first identifies the topics covered, then receives the relevant sales guidelines rather than the entire rubric.
I built checks that reject findings when their quoted evidence cannot be matched to the submitted transcript, or when they cite a rule outside the supplied packet. This makes the result inspectable: a manager can compare a finding with what was actually said. It does not make the model infallible, so the final decision remains with the manager.
Handling delayed events and failed handoffs
CRM call-log and lead-stage events can arrive in either order, and transcripts can arrive later. I separated eligibility from readiness, retaining a waiting state until the necessary evidence exists. Catch-up and recovery jobs keep processing moving when a webhook is missed, with Redis locks to prevent overlapping work.
A confirmed review can reassign a lead to another salesperson. Those CRM writes can fail, so handoff claims and recovery logic allow unfinished transfers to resume. The workflow tracks previously tried owners so a lead is not simply bounced back to someone already tried. I also built a replay harness using 210 real short calls to exercise the webhook-to-review path without writing to production.
Results, attribution and limits
According to the project’s October 2026 production records, the audit processed more than 20,000 calls, flagged more than 9,000 for review, and approximately 6,000 leads were reassigned after manager review. These are operational counts, not evidence that every flagged call was a failure or every reassigned lead converted.
The module automated the initial audit step while keeping managers responsible for the final decision. Private production records and internal project history are the source of these figures; this page does not publish customer records or transcripts. The wider DORA product was developed by a team, and teammates also contributed changes to the call-quality area.