Skip to main content
Agent QA by industry

E-commerce support call QA: delivery and returns audit

A call that says "your money will be back on your card tomorrow" and does nothing forces the customer to call again. This article covers what makes an e-commerce support call different, an illustrative seven-criterion form, checking against the order system and a dated policy version, an illustrative reconciliation of agents' promises with system records, a returns risk scenario, damaged-item complaints, quality on sale days and using repeat calls as a quality signal.

September 29, 20267 min read

Short answer

The quality of an e-commerce support call is checked with three things: did the agent find the customer's order correctly, did they explain the current delivery and returns policy correctly, and was the action they promised — a refund, a courier pickup, a replacement — actually carried out in the system? The answer to the third is not in the call: a transcript only shows what was promised. It has to be reconciled with the order and payment system.

That is exactly where this audit earns its keep: a call that says "your money will be back tomorrow" and does nothing, or promises something outside the policy, forces the customer to call again and erodes trust in the shop faster than anything else.

What makes e-commerce calls different

  • Most calls are about the same three topics: where is my order, can I return it, when will I get my money back
  • Every answer rests on system data — agents should not answer from memory
  • Rules differ by campaign, product category and payment method
  • The agent's promise becomes another team's job — the warehouse, the courier, finance
  • Seasonal peaks — sale days — increase call volume and errors

Illustrative support call form

The form below is an illustrative example. For instance, if the customer only asked about delivery status, criterion 4 does not apply.

  1. 1. The order was found correctlyThe agent identified the order number or the customer per the shop's rules and confirmed the order contents with the customer.
  2. 2. Status was given from the systemDelivery status and expected date are based on system data; an estimate was called an estimate.
  3. 3. The problem was clarified preciselyDelay, damaged item, wrong item, wrong size — each has a different rule.
  4. 4. The current policy was explained correctlyReturn window, item condition, who pays for return shipping, excluded categories.
  5. 5. The promised action and its timing were stated clearlyWhat will be done, by whom, by when, and how the customer will know.
  6. 6. No promise outside the policyThe agent did not promise compensation, timing or an exception beyond their authority.
  7. 7. The customer was told the next stepCourier visit, SMS, email or callback — the customer knows what to expect.

Verification source: the order system and the policy version

  • The order management system — the order's contents, status and history
  • The returns policy — a dated version; which policy was in force on the day of the call
  • Refund and return records — was the promised action created?
  • The courier and warehouse system record — was a pickup or replacement actually scheduled?

Criterion 4 is checked against the policy text, and the outcome of criterion 5 against the system record. The transcript is where the check starts, not where it ends.

Illustrative promise-to-system reconciliation

The figures below are an illustrative example. In one week, agents promised a specific action on 40 calls. Each promise was matched against the record in the order and payment system.

31Carried out within the promised time
6Carried out, but late
3Never carried out

77.5% of promises (31 / 40) were kept on time. The interesting part is the other 9. Reviewing them usually reveals two causes: the agent stated a shorter time than the policy — "tomorrow", say, without allowing for the bank's processing — or the promise was never recorded in the system. The first is an agent-coaching issue; the second is a process issue.

Illustrative risk scenario

Customer: "The shoes don't fit — I want to return them." Agent: "No problem, the courier will come tomorrow, and your money will be back on your card tomorrow as well."

  1. What is wrongNo courier pickup has been scheduled in the system, and the refund time depends on the bank's processing — "tomorrow" is an unconfirmed promise.
  2. In the formCriterion 5 is partial — the timing was wrong; criterion 6 is no. If the system check finds no courier order, that is a separate process problem.
  3. A correct answer"I've logged the return; the courier will come tomorrow between 10 and 2, and you'll get an SMS. Once the item reaches our warehouse the refund starts; how long it takes to reach your card depends on your bank, usually a few working days."

Damaged or wrong item complaints

  1. EvidenceThe agent asks for a photo or the packaging's condition per the shop's rules — preventing a drawn-out exchange later.
  2. Recording the causeWas the damage done in delivery, or was the wrong item sent from the warehouse? The difference matters for later analysis.
  3. The customer's choiceThe options the policy allows are stated: replacement, refund, partial compensation — the agent does not impose their own decision.
  4. CostWho pays return shipping is made clear; if the shop made the mistake, the customer does not pay — where that is the rule.

Quality on sale days

On big sale days call volume multiplies and temporary rules appear: extended return windows, delivery delays, exceptions for discounted items. During that period agents get a one-page note of the current rules, criteria 4 and 6 are checked on every call, and promise-to-system reconciliation runs daily — so a problem is found the next day, not at the end of the week.

Using repeat calls as a quality signal

In e-commerce, the most useful signal is a second call about the same order. When a customer calls because "my money still isn't back", look at the first call: what was promised, and was the timing stated correctly? Joining calls by order number requires the order number to be in the call record or the ticketing system.

Typical mistakes

  • Saying "it's on the way" without checking the system
  • Working from an old returns policy — especially after a campaign
  • Quoting a short refund time without allowing for bank processing
  • Forgetting to record the promised action in the system
  • Forgetting to ask for evidence — a photo — on a damaged-item complaint, then dragging the process out

Limits

  • A transcript does not prove a refund, pickup or replacement actually happened
  • Checking that the policy was explained correctly needs the policy version in force on the call date
  • Promise-to-system reconciliation needs the order number to be reliably linked to the call
  • Consumer-rights requirements must be checked with a lawyer

What Vexvon Audio Analyzer offers

  • You write the seven criteria as your own call standard; on every call each is judged as met, partial, missed or not applicable
  • The action and timing the agent promised are shown as transcript lines — making it easier to build the list for the system check
  • A short summary of each call saves time for whoever does the reconciliation
  • This module has no direct integration with an order system; the reconciliation is done on your side

More: Vexvon Audio Analyzer. Measuring resolution through repeat contacts is covered in first call resolution measurement, checking for false promises in unconfirmed promises in sales calls, and call fields in call recording metadata fields. Confirmation calls for cash-on-delivery orders are a separate topic: COD order confirmation calls.

First step

Pick 20 calls from last week where agents promised a specific action, and match each promise against the record in the order system. Count promises kept on time, kept late and never kept. This article belongs to the agent QA by industry section. To try it on your own recordings, get in touch.

Live demo

Ready? Let's start

See Vexvon live in a 10-minute demo.

  • A scenario built for your business
  • A live sample call
  • A tour of the platform
Get a demoorBook a meeting

Your details are used only for the demo and to get in touch.