Close looping: an operating guide to the inner loop

TL;DR

• Close looping has two jobs. The inner loop fixes the customer, in hours or days. The outer loop fixes the business, in weeks or months. This guide covers the inner loop.
• The inner loop does not fix the business by itself. It is, though, the only source of the record of resolutions the outer loop needs.
• The inner loop runs on a set of configuration decisions: what raises an alert, who is asked for consent, how fast an answer is owed, which statuses exist, who owns the ticket, and when it escalates.
• Start with a narrow alert rule and widen it as the team proves it can keep up. The commonest way these programmes die is alerting on every detractor from day one, where a detractor is any respondent in the low-scoring band of a recommendation question.
• Ask permission inside the survey. The population you may contact is smaller than the population that scored you badly, and the follow-up team should be sized against the smaller number.

What close looping is

Close looping means acting on an individual survey response rather than only counting it. The term covers two different jobs that are usually described as one.

The inner loop fixes the customer. A response arrives, an alert fires, someone owns it, they contact the customer, resolve the issue and confirm it is resolved. It runs in hours or days.

The outer loop begins where the complaints pile up. Over weeks or months, the accumulated complaints name the process that keeps producing them. Changing that process is a slower, wider job. It fixes the business rather than any one customer.

A programme can be fast, courteous, well staffed and closed on every ticket, and still meet the same complaint every month. Nothing about the system producing the complaints has changed. Each resolved alert does leave behind a record of how one real problem was put right, and the final section shows how the outer loop reads it.

Close looping is a series of configuration decisions, and most programmes make them by accident. Nearly all of them can be revisited once the programme is running. The consent decision cannot; it has to be made before the first survey goes out.

Decide what raises an alert

Settle the rule with Numr; there is no default, and the rule is specific to your programme. The question you are deciding is not "what is a bad score". It is "how sure do you want to be, before a human being spends time on a phone call, that the call is deserved". A plain threshold treats every low score as equally worth a call. Each rule below it in the table adds a signal that makes the alert more likely to deserve one.

Segmented thresholds exist because the same score does not carry the same risk everywhere. A score that raises no alert in one segment can be worth a call in another.

The trigger-word rule catches what no threshold can: a customer who rates you well and then describes something serious in the comment box. A threshold-only programme never sees that customer. The score is unremarkable, no alert fires, and the comment sits unread until someone trawls the verbatims.

In practice the rule reads each comment against a maintained list of words, with "fraud" the standing example. The list needs an owner. Someone has to add the terms that start turning up in real comments and remove the ones that only ever produce noise.

Where the line sits also depends on the question the score came from. A 6 on a scale that runs to 10 is not the same answer as a 6 on a scale that runs to 5. Write the rule against the instrument in use, not against a folk memory of what a bad score is. Benchmarks for what a good Net Promoter Score looks like will not help you place the line either; they describe aggregates, while the alert rule sorts single responses as they arrive.

Whichever rule you settle on also fixes how many alerts there will be to answer. Work that out before anyone commits to a response deadline.

Get permission first

Ask the respondent, inside the survey itself, whether they agree to be contacted by a support representative about what they have said. If they agree, the alert is generated. If they do not, it is not. Numr runs it this way in many programmes, especially in Europe, and it is the practice this guide recommends.

This is a survey-design decision, made before the first alert exists. You cannot retrofit consent onto responses you have already collected. Asking at design time also settles, per respondent, whether that customer may be contacted at all, rather than leaving the question to be argued over after the call has been made.

The population you are allowed to contact is smaller than the population that scored you badly. Size the follow-up team against the smaller number. Who answers the survey at all is a separate question from who consents; that one is covered under survey response rates.

Answer it, and faster when the process says so

Answer within 24 hours; that is Numr's general recommendation. Some accounts are already marked out as too valuable or too fragile to wait. Those high-priority or critical customers should hear back within a few hours. For everyone else you have until the 24-hour line.

The platform raises an alert on a single response within minutes of submission, not in a nightly batch. It is also normal for one survey to run two alert paths at once, each rule raising its own alerts. Those minutes say nothing about the deadline. The 24 hours run from the moment the customer presses submit until a person makes contact, and the minutes the platform took to raise the alert are already inside that window.

The deadline should follow the process, not only the score. Take a transactional survey that goes out after a support ticket and asks a CSAT question about the resolution. Suppose the ticket has already been marked resolved and the response is very negative. Or the survey asks "was your ticket closed satisfactorily" and the answer is no. That alert should be answered faster than a general low score of the same size.

A customer telling you that the thing you believed was fixed is not fixed is a worse signal than a customer who is simply unhappy. You have already had one attempt and used it up.

Decide your statuses

Whatever status set you configure, it has to separate waiting on you from waiting on them.

Numr's default set is four:

• New. The alert nobody has touched.
• Waiting on Us. The next move is yours.
• Waiting on Customer. The next move is theirs.
• Closed. The resolution is confirmed.

The platform will carry anything from two statuses to twenty. You can also configure:

• whether the status counts as open or closed;
• whether notes are required on a state change;
• whether reassignment is permitted or blocked, state by state.

The separation matters because most complaint systems collapse waiting on you and waiting on them into a single "open". That collapse is what lets a close looping queue look busy while nothing moves.

An alert parked because the customer has not replied and an alert parked just as long because nobody picked it up look identical in a system with one open state. Only the second is a failure on your side. Finding out which is which then means opening each parked ticket in turn and reading back through its notes to work out whose move was last.

Keep the right people in it

Give every alert an owner: either a named person, or one derived automatically from a column in the response data. With derived assignment, the branch code, dealer name or region that arrived with the survey data decides who owns the alert. An alert raised in a particular branch, dealer or region routes back to it rather than landing in one central queue.

Closing the loop is hard, and no configuration makes it easy; someone still has to ring a person who has just said something uncomfortable. What the platform removes is the reading and the routing, the daily work of combing responses and deciding who needs to see each one.

The ticket goes back to where the problem happened, and it carries its record with it:

• created date and due date;
• last activity and an overdue flag;
• live counts of open and overdue alerts;
• a timestamped trail of every status change, reassignment and customer contact.

Decide when to escalate, and to whom

Settle the escalation path before launch, while nothing is yet late. A path invented after the first missed alert is a path designed in anger. The pre-launch one is simply part of the configuration, done during implementation by Numr's implementation team.

An escalation rule has three parts:

• A delay. The rule waits out a configured stretch of time.
• A condition. What must still be true when the delay expires. The rule can check simply that the alert is still open, or that it has spent the whole wait in one particular status.
• A target. Who gets told: the people already on the ticket, or named people chosen by a rule.

Escalating on status is sharper than escalating on age. Take, as an invented illustration, a delay of three days. A rule that fires on age alone cannot tell an alert that has spent those days in Waiting on Customer from one that has spent them in Waiting on Us, and the two deserve different responses. A rule conditioned on a particular status can pick out the Waiting on Us alerts specifically.

Do not drown in week one

Start with a higher threshold than you think you need, so that fewer alerts are generated. Lower it as the team ramps up and shows it can handle more.

Alerting on every detractor from day one is the commonest way one of these programmes dies. The queue grows faster than the team clears it, and response times slip past the 24-hour line. The customers who did get contacted were contacted late, and a late call, however well the call itself goes, is its own message. Before long the alert feed is something people have learned not to open.

A stricter starting rule does cost you something, because some detractors will never get a call. But it keeps the queue at a size that gets cleared inside the deadline.

It is reasonable to want a number here: alerts per handler, a safe ratio, a benchmark. Numr does not publish one, and this article will not invent one. Consent shrinks the alertable population below the detractor count, the threshold sets the flow, and the threshold is adjustable. Set it where the team you actually have can answer everything it produces inside the deadline you have chosen.

Closing it, and whether to ask again

Close an alert when the issue is resolved and the resolution is confirmed with the customer. Confirmation is normally part of the resolution contact itself. The person who resolves the issue asks, in the same conversation, whether the customer considers it resolved, and the alert can be closed on that answer.

There is also a mechanism beyond that. The platform supports sending a further survey after closure, asking whether the issue was resolved satisfactorily. Numr does not use it often, reserving it for closures that were genuinely complicated or cases that were very critical.

A follow-up survey about the follow-up to a survey is a real demand on someone's patience. It adds to the effort you ask of the customer, and it spends goodwill you have only just finished rebuilding. Sent routinely, it teaches customers that answering you honestly leads to more forms.

Where the outer loop starts

Define the categories yourself. The classification is built with three levels, the depth fixed. The categories at each level are yours to set, differently for every project. Numr ships no standard tree, since a hotel group's second level would say nothing useful about a logistics firm. Two different things get classified in it.

The survey side records the problem the customer faced. It is captured through a drill-down question in the survey, or by categorising the comment afterwards.

The ticket side records how the problem was solved, which in practice means the route the resolution actually took, written in business terms. As a purely illustrative shape: support queries at level one, review of application status at level two, delay in processing application at level three.

Crossing the two shows, for a problem type customers keep reporting, which resolution paths were actually taken to resolve it. No amount of survey data answers that on its own, because the survey never sees the resolution. Most programmes classify the customer's side only and then wonder why they cannot say what should be done differently.

The inner loop does not fix the business. But each alert it resolves adds a line to the ticket side, and the resolutions that keep being needed are the outer loop's agenda.

The pre-launch list

• The trigger rule. No default exists. Settle it with Numr.
• The starting threshold. Higher than you think you need, lowered as the team proves it can keep up.
• The consent question. It goes in the survey itself, before launch, and it is the one decision that cannot be retrofitted.
• The response deadlines. Numr recommends 24 hours, a few hours for high-priority customers, and a failed resolution answered faster than a general low score of the same size.
• The status set. Two statuses or twenty, provided the set separates waiting on you from waiting on them.
• Assignment. A named person, or a column in the response data that routes each alert back to where it came from.
• Escalation. A delay, a condition and a target, settled before launch and configured by Numr's team during implementation. A condition on status is sharper than one on age.

Frequently asked questions

What is close looping in customer experience?

Close looping is the practice of acting on individual survey responses rather than only reporting them. The inner loop contacts and resolves the individual customer, in hours or days. The outer loop aggregates complaints into patterns and changes the process behind them, over weeks or months.

What is the difference between the inner loop and the outer loop?

The inner loop fixes the customer and protects one relationship at a time. The outer loop fixes the business by changing the process that keeps producing the complaints. A programme needs both. The inner loop cannot change the process on its own, but it produces the record of resolutions the outer loop reads when it does. Without that record the outer loop sees only what customers reported, never what it took to put each report right.

How quickly should a detractor alert be answered?

Within 24 hours as a general rule, and within a few hours for high-priority or critical customers. A customer saying a supposedly resolved ticket is not resolved deserves a faster answer than a general low score, because the first attempt at fixing it has already been spent.

Does every detractor need an alert?

No, and starting that way is how these programmes most often end up as a dashboard with a graveyard attached. Begin with a narrower rule, such as a stricter threshold. Answer everything it produces properly, and widen the rule as the team demonstrates it can keep up.

Do you need the customer's permission to follow up on a survey response?

Numr asks for it inside the survey. The respondent is asked whether they agree to be contacted by a support representative, and the alert is only generated if they agree. It is common practice in Numr programmes and especially the practice in Europe. Because the question sits in the survey itself, the decision is made at design time; consent cannot be applied to responses that have already been collected.

Should you survey the customer again after closing an alert?

The capability exists, and Numr uses it sparingly, reserving it for complicated closures or very critical cases. Confirmation is normally part of the resolution contact itself. Routinely sending a survey about the handling of a survey spends the goodwill the follow-up just rebuilt.