What if you knew who had the problem before they called?

Part one of this series covered getting the right conversation to the right person in time, and part two covered making sure that person starts out knowing what the company already knows. Say both are working. A customer writes in, reaches the right agent quickly, and gets a good answer. The ticket closes.

Here's a version of what can happen next at a consumer hardware company.

A firmware update for a connected home device goes out on a Tuesday. By Thursday a handful of customers have written in. One says the device "goes offline every night around 2am."

Another says it "drops whenever my mesh system does its update thing." An agent works through a few of them and finds the pattern. The problem shows up on units running the new version that are paired with a particular kind of mesh router, and a reset plus a settings change in the app fixes it. The agent writes that up in the case note, closes the ticket, and moves on.

The rest of the team does the same with theirs. The tickets get tagged as connectivity, one of the biggest categories every week, so the count doesn't stand out.

Meanwhile many more households have the same firmware and the same router, and most of them haven't written in. Some saw the app show the device offline and assumed it was their internet. Some unplugged it and tried again. A few will quietly stop opening the app. The company has no way to tell how many fall into each group, because the number it watches is how many people contacted support.

Twenty-five tickets tell you that twenty-five customers decided the problem was worth contacting you about. How many others have it is a separate question, and the ticket count can't answer it.

Those two questions lead to very different decisions. How many people complained tells you how loud a problem is. How many people are exposed tells you how big it is. Support has mostly been able to answer the first one.

A resolved ticket records more than one customer's fix. It's an observation about the product in the field: under these conditions, this symptom showed up, and this change resolved it. The customer's own words describe what they were doing. The agent's notes capture the real cause, which is often not the one the customer guessed. The resolution confirms what worked.

Telemetry might show the disconnects, but it won't show that the customer noticed because they were trying to check on things while away from home, or that a settings change in the app cleared it up.

Pull those conditions out and you have something you can check: this firmware version, this router type, this symptom. Compare them against the devices registered in your app and you get a list of customers who match.

One ticket, or even a handful, is a hypothesis about which conditions matter. Some matching customers will never hit the problem, and some who do will turn out to have a different cause. Treat the list as a starting point. Telemetry or a quick check with a sample of customers shows whether the pattern holds, and engineering decides whether it's real.

Churn models start with a customer and ask what that customer might do next. This starts with a problem and asks who else is exposed to it.

Plenty of software reads tickets now. Helpdesk AI groups conversations into topics and flags spikes. Feedback platforms cluster comments into themes and weight them by revenue. Some manufacturers already combine service records with product and sensor data to spot problems across a fleet.

The harder step is going from a single resolved case to a named list of customers who share its conditions. A theme can tell you connectivity contacts went up last week. It usually won't give you the households on the new firmware paired with that router.

Matching a ticket to the device, the app account, and the original order sounds simple. Each system knows the customer a little differently, though. The helpdesk has whatever email they wrote in from. The app has the login they set up, which might be a different email or a partner's account. The device record has a serial number, and the order sits with a retailer or the online store under another name and address.

The usual answer was a data project: get every system to agree on who the customer is, build a warehouse, clean up the fields, then build reports on top. By the time the data was ready, the question that started the project had often changed, and support questions tended to wait behind everyone else's.

Models change part of that picture. A model can read a ticket, pull out the serial number the customer typed, their email, and the order number from a pasted receipt, then look each one up where it lives. It can flag two records with slightly different names at the same address as a probable match for someone to confirm. More of the interpretation and matching can happen when you ask the question, instead of every relationship having to be defined in advance.

The groundwork doesn't disappear. You still need integrations and read access to the helpdesk, device data, app, and order system. The matching is probabilistic, so it's worth checking closely early on, and if a system never captured a piece of information, a model can't recover it. The same access controls that govern customer and device data still apply, and any outreach should stay within what customers agreed to. You just don't have to clean up and permanently unify every field before you can ask the question.

Knowing who's exposed gives you options, and contacting customers is only one of them.

Engineering may already be working on a patch, and the list tells them how many customers are waiting on it. If the patch is weeks away, you could push the settings change to affected devices through the app, or send an in-app note to the customers most likely to notice, such as people who check on the device remotely. Customers still inside the return window may be worth reaching first, since a fix now can keep a frustrating week from turning into a return. Or you look at the size of the group and decide to leave it alone. That can be the right call, as long as it's made knowing the size.

This may be the most useful case. Nearly every product carries a few known issues that bring in a small number of contacts a month and have never been worth engineering time. Leaving them on the backlog is often a reasonable decision.

Choosing not to fix something is still different from waiting for customers to discover it. If you know which setups are exposed, you can apply the workaround ahead of time or warn the customers it will hit hardest. You don't have to fix every problem, but you should know who you're asking to live with it. The defect stays on the backlog, and the customers who have it don't have to find it on their own.

The list gets more useful next to data the rest of the company already watches: app usage, premium plan subscriptions, returns, and reviews.

Look at what the affected customers did afterward. Did they keep using the app? Did they cancel the premium plan, return the device, or leave a one-star review? A ticket count tells product that people were annoyed. What the affected households did next gives you a much better sense of what it cost. Product teams weigh revenue at risk against everything else competing for the next release, and twenty-five tickets rarely hold up in that conversation. A defined group of customers, with the plan revenue attached and evidence of what happened to the ones who hit the issue, gives product a much stronger case for prioritizing it.

You can check whether this applies to your team without buying anything. Take the top five items on your current defect or improvement list. For each one, ask how many customers have the conditions, rather than how many complained. Then ask how many of them have since returned the product, canceled a plan, or stopped using the feature.

If no one can answer that for any of the five, that's where to start.

All three parts of this series come back to reading. Routing reads what just arrived and works out how urgent it is. Preparing reads what the company already knows about a customer before the conversation starts. Learning goes back through closed tickets to see who else they point to.

Software is good at the reading. The people on your team decide what to do about what it finds.

The support queue works as an imperfect sensor for the product in the field. Each closed ticket recorded one customer's problem and carried a clue about who else might have it. You can follow that clue now.