Exception Scaling Matrix: A Practical Coaching Guide
Nour
Founder, Coachful
An exception scaling matrix connects three useful things: the client's account of the present, a relevant occasion that went differently and a next action worth testing. Its purpose is to improve the next conversation and decision. It does not turn subjective ratings into a performance measurement.
This guide explains exceptions and conversational scales before combining them in an original four-part coaching worksheet. A complete fictional support-team case shows a rejected first proposal, a revised agreement, two actual handover decisions and a review that preserves the unresolved capacity problem.
Coachful is our #1 recommendation for preparing the original worksheet, keeping client responses with the coaching work and returning agreed feedback. This is our editorial workflow recommendation, not a market ranking, clinical treatment claim or guarantee that a matrix improves service outcomes.
Understand what comes from solution-focused practice
Steve de Shazer, Insoo Kim Berg and colleagues developed solution-focused brief therapy at the Brief Family Therapy Center. The SFBTA's 2025 third-edition treatment manual describes exceptions as occasions when a difficulty was absent or less severe, and scales as conversational tools for exploring a person's position and possibilities. Those are clinical practice concepts; this article applies selected ideas to ordinary coaching within the coach's competence.
The four-part arrangement below is an original planning aid. It is not a named SFBTA protocol, validated assessment, diagnostic instrument or replacement for professional training. The manual is a source for attribution, not permission to reproduce its client dialogues. The official SFBTA manual page identifies the third edition (2025).
Ask whether this approach fits the client and concern. Someone seeking help choosing a manageable action may welcome it. Someone reporting a serious incident, harassment, unsafe work or a health concern may first need an appropriate investigation, protection, management decision or qualified healthcare support. A request for a helpful exception must not divert that response.
Examine an exception without making it a success story
A useful exception is relevant to the client's concern. If the concern is unclear handover responsibility, an enjoyable team lunch is not automatically evidence about handovers. Look for a particular occasion when responsibility was clearer, even if the wider service problem continued.
Begin with the person's account and check what happened. Which action differed? Who contributed? What information, time, permissions or staffing were available? What remained difficult? A description such as “I sent the request before the receiving lead's planning cutoff” offers more to examine than “I was positive.”
Separate a potentially repeatable contribution from a favorable condition. A concise request may be repeatable. Having an unusually quiet shift, an extra specialist or an accommodating colleague may not be. Ask what would have to be agreed before using the same approach elsewhere.
Do not force ownership of every favorable event. A client can benefit from support, luck or another person's work without having caused it. Nor does one better occasion prove why the difference occurred. Treat its explanation as a possibility to investigate, rather than a causal finding.
If no relevant occasion comes to mind, accept that. The next useful conversation may concern necessary support, a smaller aim or an obstacle that has never been resolved. Our exception inquiry guide develops that exploration separately.
Give a scale meaning before giving it a number
Define one subject, one period and useful endpoints. “How clearly could you identify the customer-update owner during the last five working days?” is different from “How good is the team?” The latter can conceal several unrelated judgments.
Let the client explain the lower and preferred positions in ordinary language. An endpoint need not require perfection or control over others. A useful upper description might include knowing when a request has not been accepted and which route applies next.
In his 2001 paper Scales and Scaling, de Shazer emphasizes that a rating is an answer within a conversation and context. The same numeral from different people does not establish the same experience. That warning matters when a manager wants a single team score.
A client can use words, a range or no number. If they choose four, explore the situations and distinctions behind it. Do not tell them that they must be higher because one task went well. If they later choose five, ask what changed in their account and whether the meaning of the scale stayed the same.
Four to five is not a 25% increase in competence. The conversation has not established equal intervals or a quantitative measure of service quality. Keep operational counts, elapsed times and formal measures separately labeled.
If the goal or endpoints change, record the new question rather than drawing a continuous trend through unlike ratings. A client may first rate confidence in making a request, then decide that protecting their available work time matters more. Both can be useful conversations, but a later six on the second question is not an increase from an earlier four on the first. The matrix should preserve that change of purpose.
Connect the four parts without hiding uncertainty
| Part | What it should contain | What to keep separate |
|---|---|---|
| Present position | The concern, period, person's description and optional anchored rating | A judgment of the person's worth or a team ranking |
| Relevant difference | A specific occasion, contributions, conditions and remaining difficulty | A claim that the client caused every helpful event |
| Next useful sign | An observable distinction worth pursuing in this context | A demand for a particular score increase |
| Test and review | An authorized action, actual receiving agreement, observation and reconsideration point | An assumption that writing a name transfers responsibility |
Follow the connections. Does the selected occasion concern the same problem as the present description? Can the proposed sign occur under current conditions? Does the test require somebody else's time, permission or information? A full worksheet with broken connections is still an incomplete plan.
Keep the next sign small enough to inspect. “The next handover records acceptance or a clear refusal, and the customer still has an update owner” is testable. “Everyone becomes collaborative” supplies neither a decision rule nor an observation.
The review can lead to retaining, changing, stopping or postponing the action. It need not produce a higher score. A clearer understanding of a resource constraint may be more useful than another attempt to motivate people around it.
What question research supports, and what it does not
A 2021 experiment by Neipp and colleagues studied 246 psychology undergraduates assigned to problem, miracle, scaling or exception questions presented by computer. It examined immediate responses, rather than workplace service delivery.
Scaling produced more proposed action steps than the miracle and exception conditions, but not significantly more than the problem condition. The solution-focused conditions did not outperform problem questions on positive affect, self-efficacy or goal approach. For negative affect, the exception-versus-problem comparison was at the reported significance boundary, P=.050; the miracle comparison was P=.029.
These findings do not validate this combined worksheet or establish that additional proposed actions become completed work. The nonclinical student sample and fixed computer presentation limit transfer to live coaching. Use the study to resist claiming that every solution-focused question is superior, not to promise a particular client's result. Read the original experiment.
Worked example: two ratings reveal different responsibilities
All people, dates, records and outcomes in this case are fictional. Rosa manages a small support team. Dev leads technical triage. On 5 April 2032, they spend ten minutes reviewing unclear handovers. Rosa calls the recent experience four; Dev calls it six.
Rosa means she cannot reliably identify who will update a customer after a technical request. Dev means most requests already have an engineering category and triage entry. Averaging their numbers to five would conceal the difference. Neither has administered a formal measure.
Later that morning Rosa has a forty-five-minute individual session with coach Mina. She chooses a narrower purpose: “I want a workable way to keep customer-update responsibility clear when technical work is requested.” They do not attempt to solve engineering staffing through a confidence score.
Complete the matrix with one relevant exception
Rosa recalls a 31 March billing-query handover. Dev explicitly accepted the technical review, and Rosa remained the customer contact with a visible update time. The query still took time to investigate. What differed was that Rosa did not mistake a request for an accepted transfer.
Dev happened to have capacity that afternoon. Rosa can repeat an explicit request and a clear communication field; she cannot reproduce spare engineering time by herself. Her completed worksheet makes that distinction visible.
| Part | Rosa's completed entry |
|---|---|
| Present position | Recent working week: four. Lower endpoint: I cannot identify the next customer-update owner or a route for resolving the gap. Preferred endpoint: I can identify the update owner and an honest next response even when technical acceptance is pending. |
| Relevant difference | 31 March: Dev explicitly accepted technical review; I retained customer communication and its update time. My clear request helped. Dev's available capacity also mattered. |
| Next useful sign | For two selected requests, record technical acceptance or refusal explicitly, with a named customer-update owner and next update time. |
| Test and review | Propose a one-day test to Dev. No automatic transfer on sending. Seek the operational owner's decision if technical capacity is unavailable. Review both records together on 7 April before any expansion. |
The preferred endpoint concerns Rosa's understanding and practice. It does not mean every customer query is resolved immediately. No one promises that two selected requests represent the whole queue.
Obtain the receiving lead's real agreement
At 14:00 on 5 April, Rosa and Dev use a separately agreed fifteen-minute discussion. Her first proposal says, “Put your name beside technical owner when I send the request.” Dev declines: “That would imply I have accepted work before checking capacity. I cannot agree to that.”
Rosa revises it: “I will name you as the requested technical lead, with status pending. Your explicit acceptance changes that status. I remain the customer-update owner throughout this test. If you cannot accept, I ask Amir for a routing decision rather than treating silence as yes.”
Dev accepts the revised two-request test and two brief response checks the next morning. They agree that an urgent incident uses the existing incident route immediately. This routine test does not change staffing priorities or grant Rosa authority to assign engineering work.
Amir is the operations lead authorized to decide the routing of unaccepted routine work. His involvement is a real management decision, separate from Mina's coaching and from Dev's technical acceptance.
Carry out both decisions and preserve the blocked case
On 6 April at 09:00, Rosa sends the first selected request: “Routine billing display query; technical review requested from Dev. Customer-update owner: Rosa. Next update: 11:00 UTC today. Please confirm acceptance or decline.” Dev checks and explicitly accepts technical review. Rosa records acceptance and sends the promised customer update at 11:00, stating that technical review is underway.
For the second selected request at 10:00, Dev replies that an incident has consumed the remaining technical capacity. He declines this routine request. Rosa records “not accepted” and asks Amir to decide its route. She does not replace Dev's refusal with a positive status.
Amir answers at 10:20: “Keep it in routine triage; no engineering owner has accepted it. I authorize deferral to the 8 April 10:00 UTC triage decision. Rosa remains the customer contact. Tell the customer the current position today.” His decision authorizes a deferral, not a completed technical review.
At the promised 15:00 update Rosa sends: “Technical review has not yet been accepted because current incident work takes priority. I remain your contact. The next triage decision is due on 8 April at 10:00 UTC; I will update you after that decision.” The case does not claim the customer has read or endorsed either update.
The two records now show one accepted technical review and one unaccepted request with a routing decision. Both have an explicit customer-update owner, and both promised updates were sent. That is not two resolved customer problems or a 100% technical-acceptance rate.
Review the actual difference before claiming progress
Rosa and Dev complete their ten-minute review on 7 April. They use two minutes for the two statuses, three for what differed, three for conditions and two for a decision. These are shared elapsed minutes, not ten minutes of work divided between them.
Rosa chooses five on her own unchanged scale: “I could explain who would communicate in both cases, including the refusal. The technical wait is still a problem.” Dev remains at six for his technical-triage account. They keep both descriptions and do not combine them into a team improvement percentage.
Their completed decision says: “Retain the distinction between requested and accepted technical work in these two records. Rosa's update ownership stayed clear. Do not expand the pilot yet. Amir's deferred triage decision remains due on 8 April; capacity for a further five-request test has not been agreed.” They have made a decision about the completed trial without claiming later adoption.
On 8 April at 09:00, before that triage decision is due, Rosa has a fifteen-minute coaching review with Mina. Rosa says the clearer record helped her communicate but did not reduce the frustration of making a customer wait. They retain that mixed result. This article does not report the later triage answer or the final resolution of either technical query.
Mina later sends this agreed coaching comment through Rosa's private client conversation: “Your first proposal assigned acceptance before Dev could decide. You revised it after his refusal. In the test you kept the blocked status visible and sent the promised update. What do you want to retain, without claiming the capacity issue is solved?”
Rosa reads and answers: “Keep requested and accepted separate. I will not add five more cases without the receiving team's agreement.” This returned comment is actual case feedback, separate from Mina's internal worksheet review or any future operational approval.
Count the whole bounded coaching and coordination cycle
| Person | Actual active minutes | Total and agreed ceiling |
|---|---|---|
| Rosa | 10 initial discussion; 10 preparation; 45 coaching; 15 pilot agreement; 10 first-request coordination; 15 second-request coordination; 10 joint review; 15 coaching review; 5 reading and answering the returned comment | 135 of 150; 15 remain |
| Mina | 15 preparation; 45 session; 15 review; 10 writing/sending the comment and reading Rosa's answer; 10 notes | 95 of 100; 5 remain |
| Dev | 10 initial discussion; 15 agreement; 5 first-request check/acceptance; 5 second-request check/refusal; 10 joint review | 45 of 50; 5 remain |
| Amir | 5 reading the routing request, deciding and sending his answer | 5 of 5; no reserve |
The named participants use 280 person-minutes. Rosa's request allocations include reading the replies, the actual customer status messages, Amir's exchange and recording both decisions. They are not pure form-filling time. Mina's written feedback and Rosa's reply have their own counted allocations.
This account covers coaching and pilot coordination, not the technical investigation, the customer's time or the team's unrelated service work. The historical 31 March event is a recalled example, not additional work repeated inside this trial. Available minutes belonging to one person do not authorize work for another.
Use the worksheet and review routes accurately in Coachful
Prepare an original Form or Worksheet with the four parts and explain the audience before assignment. Use client language and an appropriate response format. The matrix is not a built-in diagnostic test, and software does not establish whether an operational transfer was accepted.
Keep confidential customer details and technical records in their authorized work system. The coaching resource can contain an agreed, minimized description. Giving a coach a selected example does not authorize copying the whole support queue or showing the private coaching account to colleagues.
Coach review of a submitted response is private to the authorized coach team. A Reviewed status is not feedback delivered to the client. In the case, Mina returns her actual comment through Rosa's private client conversation, with its authorized staff audience understood; Rosa reads and answers there.
Before sensitive sessions, inspect recording and recap settings. Recaps are automatic by default. Use Approve before sending and check the relevant session-type override before describing a recap as held for review; use the available Send or Keep private choice appropriately. A setting change does not recall an already sent copy.
For collaborative rating conversations, see the collaboration scaling guide and inspect Coachful's features for the actual workflow.
Apply it in a practical sequence and troubleshoot the result
- Choose the concern and scope. Agree whether coaching is appropriate, what period is being discussed and what needs another route.
- Describe the present. Establish meaning before an optional number. Keep different people's referents visible.
- Examine one relevant difference. Identify contributions, support and conditions without demanding a positive story.
- Choose a useful sign. Describe an observable distinction rather than prescribing a score rise.
- Obtain actual agreements. Check authority, receiving capacity, information, stopping conditions and review time.
- Act, record and reconsider. Separate attempted actions, received replies, completed outputs and unresolved outcomes.
If the client feels scored, remove the number and discuss the concrete description. If the exception relied on extraordinary help, check that help before transferring the action. If the plan sounds clear but no recipient agrees, it remains a proposal. If a test exposes a structural constraint, report that constraint rather than setting another confidence target.
If a higher rating conflicts with operational evidence, explore both without forcing agreement. A person may feel clearer while a queue remains long. Equally, better service counts do not require them to report relief. Keep their account, the observed work and the next management decision distinguishable.
Frequently asked questions
Is an exception scaling matrix an established SFBTA protocol?
The exception and scaling concepts come from solution-focused practice. This four-part worksheet is an original coaching arrangement, not an SFBTA assessment or validated combined protocol.
Must the client find an exception?
No. Accept that none is available or relevant. Explore needed conditions, support or a different question rather than assigning the client a success story.
Can I average the team's numbers?
First establish what each rating means. These conversational numbers do not automatically share anchors or equal intervals. An average can hide different responsibilities and experiences.
Does a higher number prove the experiment worked?
No. Ask what changed and compare that account with the actual action and outcome. This worksheet does not establish causation or a percentage gain in performance.
What if the test is blocked by capacity?
Keep the refusal visible, preserve any continuing owner and use the appropriate decision route. A coaching question cannot create another person's availability or authority.
