The Six
Sigma Problem
Solver

An agent who gets a locked-out customer back into their account has done something valuable. The customer needs help now, and a lecture on root causes would be a fairly dreadful substitute for access. But if agents repeatedly have to rescue people from the same failed reset, the rescue has a second effect: it can make the process look healthier than it is. The case closes. The customer’s earlier failed attempt may disappear into a different system. From a distance, all is well. From the desk, everyone knows the little trick that makes it work.

Lente’s opening challenge is to pause before patching. She is not asking people to leave customers stranded while they conduct a miniature research project. She wants them to notice the difference between helping this customer and improving what the next customer will encounter. A temporary manual step can contain the damage. It needs a record, an owner and an end point, or it quietly becomes the procedure. Give duct tape enough employee-of-the-month awards and somebody will eventually call it architecture.

Start with a workaround diary. Each time the team has to send another reset link or talk someone around the same failure, record what happened, when, and which path failed. Do not record personal details beyond what your organisation permits. Even a simple tally can expose demand that the resolution dashboard misses. A workaround is a clue, and its frequency tells you whether you are looking at a rare exception or at the ordinary way the process now functions.

The book uses DMAIC as its larger compass: Define the problem, Measure what happens, Analyse the cause, Improve the process, and Control the result so it lasts. Our agent does not have to become a certified statistician overnight. The first move is more modest and more radical: refuse to confuse a successfully handled contact with a successfully designed journey.

“The reset system is useless” might be a fair expression of frustration. It does not tell us where to look. The book introduces SIPOC as a quick sketch of Suppliers, Inputs, Process, Outputs and Customers. For this case, what supplies the reset request? What information enters? Which steps generate, deliver and use the link? What counts as a successful output? Who needs access restored? The sketch will be rough. That is fine. It should show where people and systems hand work to one another.

Now walk the same route from the customer’s side. They ask for a reset, wait for the email, open it, follow the link, discover that it has expired, and call for help. Lente calls her one-page version a Customer Journey Map Lite. SIPOC sketches the mechanics; the journey map shows the moment someone’s patience ran out and the point where an agent had to absorb the failure. Put the two together and you have a much clearer crime scene than a green “contacts resolved” figure.

This also stops a common mistake in waste hunting: calling every step you dislike waste. An identity check may protect a customer and be required for security, even if it adds friction. A second login attempt caused by a link that expires before it can realistically be used adds no such protection unless the security rationale and evidence say otherwise. Lean examines flow and waste; Six Sigma examines defects and variation. The book brings those habits together, separating customer value, necessary supporting work, and steps that consume time without earning their place. Its TIMWOODS list helps name waiting, rework, extra handovers, defects and other forms of waste. It does not give us permission to delete safeguards because they look slow on a flowchart.

One useful question is: What outcome does this step protect, and can we protect it more simply? In the reset journey, a security setting and an access problem may both be real. Seeing the process clearly lets you investigate that trade-off without blaming the customer for being slow or the agent for needing a workaround.

The book’s most useful cast of characters is four voices. The customer says what the failure feels like: “I followed your instructions and still cannot get in.” The associate knows which rescue steps happen every shift and how much extra work they create. The business has obligations around security, cost and service. The process may leave traces such as expiry events, repeat attempts, elapsed time and contact volume. Each witness sees something the others may miss.

The aim is to put these accounts together, not to appoint the loudest one as judge. A handful of angry messages may point to an important defect but cannot tell us its full frequency. A low contact count could mean customers succeeded unaided, or it could mean they gave up. An agent’s account of the workaround may explain why a dashboard looks reassuring. Lente’s point about frontline credibility is that lived experience becomes more useful when it can be linked to a pattern, a customer quote and a measurable effect.

She then asks the reader to turn the customer’s words into something critical to quality, or CTQ. “I cannot get into my account” suggests a requirement: an authorised customer should be able to complete a secure reset within a reasonable time and with a clear way to recover when it fails. That description tells us what success should feel like. To measure it, we might examine the proportion of authorised attempts completed without agent help, the time taken, and repeat contact after a failed reset. We would agree a sensible target only after checking the current baseline and the security requirement. A beautifully quick journey that makes accounts less safe is a poor victory.

For our case, the most revealing place to listen may be the handover between system and person. When does the customer stop being able to solve this alone? What does the agent do next? And is that work visible to the people who own the reset journey? A complaint becomes an improvement lead when those questions produce evidence someone can test.

There is an enormous difference between “password resets are broken” and a problem statement that specifies what failed, where, over which period, how often, and with what effect. Lente’s test is wonderfully unsentimental: if a leader hears the statement in a lift, can they understand why it matters without a twenty-minute tour of your frustration?

Let us make the example tangible with invented figures for illustration. Suppose a team examines 50 reset attempts in one week. Twelve links expire before completion; seven of those customers contact support. Its case statement could read: “In a one-week sample of 50 reset attempts, 12 links expired before completion and seven affected customers contacted support. We are testing where the journey fails and whether the expiry setting contributes.” Those figures belong only to this teaching example, not to the book’s account of an actual incident. In your own case, use observed figures and state how they were gathered. A direct customer quote can add the human consequence, provided it is gathered and shared appropriately. If the data is incomplete, say so. A small honest sample is more useful than a polished number with mysterious origins.

The statement does two jobs. It gives the team a shared definition of the problem, and it resists the urge to smuggle a preferred solution into the opening sentence. “Extend the link to ten minutes” is a proposal, not yet a diagnosis. It may be right; first check whether the email was delayed, the page rejected a valid token, the instructions caused confusion, or several causes overlap.

Then add the book’s “What happens if we do nothing?” line. If failed resets continue at the observed rate, what might customers, agents and the business carry next month? A cautious estimate could include repeat contacts and handling time, labelled as an estimate with its assumptions. The point is to make inaction a decision with a visible cost, not to manufacture an apocalypse in a spreadsheet.

The book’s password-reset example offers a possible trail: the link expires quickly; the default is set to sixty seconds; nobody changed the default after testing; the release process lacked a check for that setting. That is an illustration of the 5 Whys, not a verdict on every failed link. In a live investigation we would verify each step and look for other causes before declaring the case solved.

The valuable part is the shift away from the easy culprit. “The customer took too long” and “the agent should explain it better” can sound plausible from separate desks. Neither establishes why a reasonable attempt failed. Ask what failed, for whom, in which circumstances, and where it did not fail. Did it happen across browsers? Were emails arriving late? Were some links used successfully under the same settings? The book calls this Is/Is Not thinking. It helps rule out attractive guesses before somebody invests in fixing them.

Lente is refreshingly practical about how root cause work happens. You may find one answer in a quick email, another in a log, and a third from the person who owns the release checklist. The fifth “why” will rarely arrive on cue, wearing a name badge that says ROOT CAUSE. Keep the trail open where the evidence runs out. A hypothesis is useful because it can be tested; it becomes dangerous when repeated as a fact.

Meanwhile, customers still need access. Contain the immediate harm with an approved temporary route. Record the exception and agree when it will be retired. That distinction runs through the book: the temporary rescue protects someone today, while the root cause fix changes what tomorrow’s customer encounters. Both can be necessary. Only one closes the recurring case.

If the team finds a broken link in the reset instructions, correcting it with the owner may be a Just Do It, or JDI: a known cause, a small change, low risk and a useful benefit. Document the before and after. If the suspected defect is the expiry setting, even a change to one number can alter account security. The authorised owner must assess the trade-off and decide on a safe test. Watch both successful resets and unintended effects. The book’s scientific rhythm is to observe, ask, propose, test, analyse, report and iterate. Being wrong in a small, safe test is useful information.

Suppose instead that the reset depends on several teams, requires a new recovery path and raises a real trade-off between access and fraud prevention. That calls for a bigger decision. Lente introduces the PR/FAQ as one way to write the proposed future from the customer’s perspective, then answer the difficult questions before building it: who benefits, what changes, what might go wrong, what will it cost, and how will we know it helped? It is a proposal tool in this playbook, not a magic Six Sigma form that every problem requires.

This range matters. Not every irritation deserves a six-month steering committee. Nor should a frontline worker change a security rule alone because the workaround is irritating. A JDI, a contained pilot and a larger proposal are different responses to different levels of uncertainty, risk and authority. The reader’s task is to show what the evidence supports and what decision remains with the person empowered to make it.

That is also why the book treats escalation as part of problem solving. A strong case contains evidence, impact and an ask. Find the actual process owner: the person who can change the relevant step or commit the necessary resources. The person who knows the work best may be a brilliant witness without having that authority. An excellent case sent to the wrong inbox can age there like a forgotten yoghurt. Lente also cares about the frontline worker’s credibility: documenting useful small wins and sending well-aimed cases can change how their judgement is heard. It cannot guarantee that every proposal will be accepted.

A fix that works in Tuesday’s test can still fail on Friday’s release. Lente introduces Poka-Yoke, or error-proofing, to make the correct action easier and a repeat defect harder. In our case, that might mean a release check for reset settings, a clear warning when an email is delayed, and a way to spot expiry failures promptly. Each suggestion would need to fit the confirmed cause and security rules. The idea is to build quality into the path rather than asking somebody to remember to save it every shift.

Now return to the four voices. Can authorised customers complete the journey reliably? Are agents using the rescue less often? Does the process show fewer failed attempts and repeat contacts? Has the business kept the safeguard it needs? Compare a suitable period after the change with the baseline, and keep an eye out for a new failure introduced by the fix. Control, the last letter in DMAIC, is the discipline of checking whether improvement holds after the launch email has stopped collecting applause.

If the workaround remains, give it an owner and a sunset date. If the issue crosses team boundaries, keep the handover and decision owner visible. If the numbers improve but customers still say they cannot get in, listen again. The book’s ending is about credibility built from this kind of follow-through: the frontline person notices, the team tests, someone with authority acts, and the customer meets a better process next time.