How can AI help me understand why returns, complaints or delays keep happening?
18 October 2026
How can AI help me understand why returns, complaints or delays keep happening?
AI is useful when the reasons are scattered across customer emails, return codes and operational systems. It can classify the language, compare patterns by product, supplier or process and suggest a hypothesis, but a manager must verify cases and measure whether a change reduces the repeat issue.
What AI can find that a complaint count cannot
AI can help by turning scattered returns, complaints and delay records into a consistent view of the problems customers actually describe. It can group similar accounts, connect them to products, suppliers, shifts or delivery routes, and show which patterns are growing. That is a starting point for investigation, not proof of a root cause. A manager still needs to inspect examples and test the proposed explanation.
Imagine a small retailer with 200 returns a month. Its spreadsheet says 60 were marked 'wrong item'. Customer emails tell a more useful story: some orders were picked incorrectly, others used an ambiguous size description, and a third group received a substitute without warning. Counting the return code alone would send the team towards the warehouse, while the real fixes may sit in product information and customer communication. Language models are useful for extracting those distinctions from free text. Ordinary reporting is often enough once the labels are clean.
Start by bringing together a modest sample: order date, item, supplier, promised and actual delivery dates, return code, complaint text, outcome and any internal handover notes. Give each record a stable case ID. Remove details that are not needed for the analysis. Ask the system to assign a short issue label and cite the exact source sentence that supports it. For every proposed cluster, review ten original cases before changing a process. If the source sentence does not support the label, correct the taxonomy before scaling up.
This is worth doing because the issues are not interchangeable. In a 2026 release about 2025 fashion purchases, Citizens Advice reported 3,222 complaints about faulty goods, 2,360 about delivery failure or delay, and 2,079 about trouble returning unwanted goods. Those figures concern its consumer service and fashion purchases, not all UK retail. They illustrate why a single 'customer problem' total hides very different operational failures. Source: Citizens Advice consumer service figures.
How to investigate the pattern without confusing correlation with cause
Make the question narrow. 'Why are complaints rising?' is too broad. 'Why did late-delivery complaints for supplier B rise in September?' can be tested. Compare the affected cases with similar orders that arrived on time. Look at fulfilment date, carrier scan, promised date, stock availability and whether the customer received a proactive update. AI can summarise the differences and identify missing fields, but it cannot invent the missing carrier scan or prove that supplier B caused the delay.
Use a simple sequence: detect, sample, verify, test and measure. First, chart the rate per 100 orders, not just the raw count. Second, read original cases from the highest and lowest periods. Third, have an operational owner check whether the proposed explanation matches what happened on the ground. Fourth, change one controllable factor, such as a clearer sizing guide or earlier stock cut-off. Finally, compare the next four to eight weeks with the original baseline. Keep an eye on seasonality and order mix. Ten complaints after 100 orders is worse than 15 after 1,000.
A useful weekly output has five columns: emerging theme, number and rate of affected cases, representative case IDs, likely contributing factors, and the human owner of the next check. Do not ask AI to assign blame to named staff. If it suggests a 'problem employee' from a few notes, that is a warning to examine workload, training and process conditions instead. A pattern can be real even if the model's explanation is wrong.
Here is a practical example. If returns labelled 'damaged' cluster around one product but also around one packaging change, photograph five returned items and compare packaging batches before blaming the courier. If complaints mention 'nobody called me', trace the notification workflow and failed sends. The fastest useful answer may be a broken rule in an existing system. You do not need an autonomous agent for a broken email trigger.
What data, tools and budget are needed
You do not need a large data science project to begin. For a first pass, export 100 to 300 recent cases from your CRM, helpdesk, ecommerce system or job management software. Use a spreadsheet to calculate rates and trends. Use an approved business AI account to classify free-text comments in a controlled sample. Check 30 to 50 classifications manually and record disagreement. If the labels are unreliable, improve the definitions before adding more data. If your team already uses Power BI, Looker Studio or a helpdesk report, use it for the charts rather than commissioning a new platform.
For planning, a DIY review might take a manager six to twelve hours over two weeks, plus existing software licences. A narrowly scoped external analysis may require several days of data cleaning and workshops; request a fixed-scope quotation instead of assuming a per-seat AI fee covers the work. Treat any £1,000 to £5,000 pilot budget as a planning allowance, not a market price or a Precise Impact AI quote. The real cost driver is usually reconciling inconsistent case IDs and categories across systems, not the number of prompts.
Avoid copying whole mailboxes into an AI tool because it seems easier. A useful minimum dataset is case ID, dates, product or service type, issue description, operational events and outcome. Names, addresses, card details and unrelated correspondence can usually be removed or masked. Check your contracts and data protection arrangements before transferring customer records to a vendor. The ICO's AI and data protection guidance covers accountability, transparency, lawfulness and accuracy. Its guidance is under review following the Data (Use and Access) Act, so check the current position before building a lasting workflow. Source: ICO guidance on AI and data protection.
Set a retention period for the analysis copy, restrict access, and document who can see raw text. If you cannot access the underlying records lawfully or consistently, fix that first. An AI summary built from a partial inbox and an outdated spreadsheet can look precise while missing the cases that matter most.
Where human judgement and consumer rights must remain in control
Use AI to identify patterns, draft summaries and suggest where to investigate. Do not let it decide whether a particular customer gets a refund, whether a complaint is 'valid', or whether an employee caused a failure without a person checking the facts. An apparently similar set of returns may contain legally different situations: a faulty item, an unwanted distance purchase, a personalised product and a business-to-business order do not all follow the same rules.
For UK consumer sales, GOV.UK says a full refund must be offered when an item is faulty, not as described or not fit for purpose. For many online, mail and phone purchases, customers can cancel within 14 days of receiving an item, then have another 14 days to return it. There are exceptions, so use the applicable policy and law for the actual transaction. An AI classifier must not turn a legal entitlement into a discretionary customer service gesture. Source: GOV.UK guidance on returns and refunds.
A manager should inspect the original complaint before acting on a model-generated theme. In particular, check whether the AI has confused a customer's description of a delay with the actual service-level agreement. A two-day wait may be a breach for an emergency engineer visit but perfectly normal for a standard order. Likewise, a customer may mention 'refund' in an email asking about the process, not in a complaint about a refused refund. The model should preserve uncertainty and offer a route to the source record.
Keep a clear escalation route for safety issues, vulnerable customers, possible discrimination, data breaches and legal threats. Those should not wait for a weekly pattern report. The operational gain comes from faster detection of repeat failures while individual cases still receive fair attention. If your system makes both quicker, it is working. If it merely produces an attractive dashboard while customers wait longer, stop and redesign it.
A four-week pilot that shows whether this is worth doing
Week one: choose one issue with enough cases to measure, such as late deliveries or repeated returns for one product family. Write down its current rate per 100 orders, average time to resolve, refund cost and the number of staff hours spent reviewing cases. Keep a list of exclusions. Do not combine every type of complaint into one pilot, because each has different causes and remedies.
Week two: export a defined sample, remove unnecessary personal data, and have two people independently label 30 cases. Agree the label definitions before asking AI to classify the rest. Require the tool to return the relevant source excerpt and a confidence note. Review the labels where the tool is uncertain or where the outcome could affect a customer. If too many labels are wrong, the appropriate action is to revise the data and instructions, not to automate the next step.
Week three: select one suspected cause with an owner and a testable action. Perhaps customers selecting a particular size return it because the guide uses inconsistent measurements. Update the guide for that product family, note the date, and avoid changing several other things at once. A supplier, carrier or front-line colleague may disagree with the AI's interpretation; ask them. Their operational knowledge is part of the evidence, not an obstacle to adoption.
Week four: compare the early trend, but be honest about the limits of a short test. Track the relevant rate per 100 orders, resolution time and cost, then keep measuring for another month if volumes are low. A useful pilot leaves you with a repeatable issue taxonomy, cleaner records and a named owner for each fix. Even if AI adds little beyond a spreadsheet, you have learned where your process is failing. That can be a worthwhile result.
When this is not right for you
Do not buy AI analysis if you have fewer than a handful of cases per month, cannot reliably link complaints to orders, or have not yet read the recent complaints yourselves. Start with a shared case log and a weekly 30-minute review. If the same issue is obvious to staff and customers, fix it. There is no prize for using AI to rediscover a missing delivery notification or an inaccurate product photo.
It is also a poor first project when cases involve highly sensitive information and you have no approved way to process it, or when managers want a tool to name staff to blame. The right response may be a process review, consumer-law advice or better supplier management. A simple rule-based alert can outperform AI when a precise signal already exists, such as every order more than two days beyond its promised date. Use AI for the messy language and cross-system patterns that ordinary filters miss.
If you have a steady flow of cases, an owner willing to test fixes, and permission to use the data safely, this can be an excellent modest project. Start small and judge it by fewer repeat issues, faster fair resolutions and clearer decisions. If you want help scoping that first review, a short conversation should establish whether AI is needed at all.
Is This Right For You?
This is a good fit if you have a steady flow of cases, can connect them to orders or jobs, and have someone who can act on the findings. Begin with one issue and a four-week pilot.
It is not right if the cause is already obvious, records are too sparse to compare, or you have no approved way to handle customer data. A weekly manual review or simple rule-based alert may be better.
Frequently Asked Questions
How many complaints do I need before AI analysis is useful?
A few dozen similar cases can reveal a theme, but rates become more trustworthy with a larger sample and a clear denominator such as orders or jobs. For very low volumes, read every case manually.
Can AI identify the root cause automatically?
No. It can propose patterns and hypotheses from the records it sees. A person must check original cases, operational events and the result of a targeted change before calling something a root cause.
Which software should a small business use first?
Start with your existing CRM or helpdesk exports, a spreadsheet and an approved business AI account for text classification. Add a reporting tool only if the current view is too slow or inconsistent.
Should we put customer emails into a public chatbot?
Not by default. Use an approved business service with suitable data terms, minimise personal information, control access and check retention and transfer arrangements first.
Can this help with service delays as well as physical returns?
Yes. Link complaint language to promised and actual dates, job stage, handovers and notification events. Compare the rate of delays across similar work before blaming a person or supplier.
How do we measure whether it has worked?
Track repeat issue rate per 100 orders or jobs, resolution time, refund or rework cost and hours spent investigating. Record a baseline and check whether a specific process change improved it.
Should AI decide refunds for customers?
No. It may flag cases for review, but a trained person should check the transaction, evidence and applicable UK consumer rights before deciding the outcome.