Why customers call: contact reason analysis for e-commerce support

Ask a support leader why customers call and you will usually hear a confident answer: “where is my order”, returns, payment problems. Ask for the numbers and the answer gets vaguer. Most contact centers tag calls with a disposition code chosen by the agent in the last seconds of a call, often the first one on the list. The result is a reason report that tells you what agents click, not why customers call.

Contact reason analysis done properly is one of the most useful things a support team can offer the rest of the company, because call reasons are a direct list of what customers could not do for themselves. This guide covers how to build a reason taxonomy, how to separate avoidable calls from the rest and how to turn the result into fixes.

What a contact reason is

A contact reason is the thing the customer was trying to get done or get fixed, stated in terms of the customer's problem rather than your org chart. “Delivery” is a department. “Package marked delivered but not received” is a reason. The difference matters because only the second one tells the logistics team what to do.

A few rules keep reasons useful:

• One primary reason per call. Calls can touch several topics, but the one that made the customer pick up the phone is the primary reason. Keep secondary reasons as extra tags.
• The customer's reason, not the agent's action. “Refund issued” is what the agent did. “Item arrived damaged” is why they called.
• Read the whole call. The stated reason in the first sentence is sometimes not the real one. A customer who opens with “I need to change my address” may be calling because the order is already late.

Build a taxonomy in three levels

Start small and let the data refine it. A workable e-commerce taxonomy has three levels: a group, a reason and, where it earns its place, a subreason.

Tips for building it:

1. Read a few hundred calls before deciding categories. Group them by hand, then name the groups. Do not start from the list you already have in your phone system.
2. Keep it to 25 to 40 reasons. Fewer hides patterns; more makes agents and models inconsistent. Add subreasons only for the reasons large enough to need them.
3. Define each reason in a sentence with two example phrases and one near miss. The definition is what makes counts comparable month to month.
4. Include “other”, and watch it. If more than a small share of calls lands in “other”, the taxonomy needs a new category. Review the “other” calls every month.
5. Version the taxonomy. When you rename or split a reason, record it, so a jump in a chart is not an artifact of relabeling.

Doing this by hand for every call is not realistic. When every call is analyzed and sorted against your own topic list, the counts cover the whole month rather than a sample, and rare reasons are not lost. Our piece on moving from a sample to every call shows why that matters for small but costly reasons.

A note on real numbers

To see what a reason breakdown looks like, take the public showcase on the case study page: 873 role-played calls from a public research corpus, all analyzed. The most common reasons were a new booking or appointment (212 calls), a new order or purchase (183) and a change or cancellation (177), followed by general information (113), a problem with a product or service (83), a refund or compensation (36) and the status of an order (29). These are demo calls, not an e-commerce store, so read the table above as the format to aim for, not as a benchmark. The useful point is that a single month of counted reasons already ranks where the work is.

Measuring avoidable contacts

Not every call is a failure. A customer who wants to buy something or ask about sizing is doing what you want. The calls worth removing are those that exist only because something upstream went wrong or was unclear. A practical split:

Then compute, per reason, three numbers: how many calls it generates, what share of those are avoidable and how often the same customer calls back about it. Multiply the call count by your cost per call and you have a ranked list in money, not just volume. Be careful with causation: a reason that rises alongside a campaign may be a symptom of the campaign, so compare like with like and check the calls before claiming a cause.

Turn reasons into fixes

A report of reasons changes nothing. A brief to a named team does. Use a one-page format for each fix:

• The reason and its size in calls per month and its trend.
• Three to five customer quotes with links that play the moment. Product and web teams rarely react to a chart. They react to hearing a customer try to apply a code four times.
• The suspected cause and what is not known yet.
• The proposed fix and the team that owns it.
• The measure of success, for example fewer calls with that reason within a month of the change.

Then check afterwards. A fix that does not move the number is information, too. Over time the list becomes a shared backlog between support and the rest of the company.

Some reasons deserve a faster path than a monthly brief. A sudden jump in one reason is a spike worth alerting on, and reasons that go together with threats to leave feed the daily list described in churn signals in customer calls.

Common mistakes

• Counting agent dispositions as reasons without checking them against the calls.
• Changing the taxonomy every month, which breaks trends.
• Reporting volume without avoidability, so the biggest reason gets attention even when it is a healthy one.
• Presenting numbers without a way for the product team to hear a call.
• Treating the exercise as a one-off. Customers' reasons change with every release, season and carrier.

For online stores and subscription businesses, the e-commerce solution page shows how contact reasons, possible product defects, FAQ gaps and refund searches fit together.

Call content