Making relational public services ordinary

Ask participants to bring one situation involving repeated contact, a boundary, and a decision. They should remove identifying details. Make Asha available so nobody needs to disclose a live case. Check whether participants are here to learn, to recommend a change, or to take a decision; don't blur those mandates.

Open the tool and load Asha before the session. Rehearse switching between the case and working record. Confirm that participants can open the site from their work devices. A sheet of paper is an equivalent working surface. One group member may keep the group record, but this tool doesn't synchronise between browsers.

A producer should allocate stable groups, handle late arrivals, and manage return. Without a producer, prepare the groups in advance and avoid changing them. Keep an equivalent group in the main session for anyone unable or unwilling to join a breakout. Check the actual platform's behaviour; the transition allowance is a planning allowance, not a technical guarantee.

State that this isn't a place to decide an urgent safeguarding, clinical, or statutory case. Existing escalation arrangements continue to apply. Don't record small-group case discussions. Public shareback should describe patterns and proposals, not identify the people involved.

The idea. Organisations select and translate information. A person's purpose may become a category, a task, and a count. Each translation affects what the organisation will do next. The exercise isn't an accusation that the record is false or that the worker doesn't care.

Introduce it. 'Keep one situation in mind where useful work depends on an exception. We'll follow what happens to the person's account, then ask what would let the next response be different.'

Take a one-sentence chat contribution; don't run a full introduction round. Read Asha's account slowly. Show the three representations together. Ask only: 'Which important part of Asha's account is absent from the management report?' Wait for answers before asking what action the report makes likely.

A useful response. 'The clash with her shifts has become tenant unavailability, so another appointment could reproduce the same problem.' This identifies a change in meaning and a plausible consequence. 'The system is uncaring' is an interpretation to unpack, not an adequate map.

Likely confusion. Someone may argue that a better referral would solve everything. Ask what would count as completed help, and who would know whether it happened. Someone else may want a richer record of every life detail. Ask which missing detail would change the response. More data isn't automatically better understanding.

Transition. 'Now trace the same movement in one situation you can examine. Don't fill unknown stages with what ought to happen.'

Purpose. Move from a general complaint to a specific point at which the account no longer supports a useful response.

Visible task. 'Trace one situation from the person's account to the next contact.' Output: one annotated route. The group uses the tool's first three steps or paper. This is one cumulative mapping task, not a demand to finish the entire tool.

Within the 15-minute work period, allow about 2 minutes to choose a case, 8 to trace its route, and 5 to mark one loss and who carries its consequences. Keep the group together throughout. Put the stages in an accessible message or page before sending anyone out.

Worked example. Asha's account includes conflicting appointment and shift times. The record says 'tenant unavailable'; the dashboard treats the request as responded to. A repeated appointment is a plausible next event, but remains an inference. Annotate that difference.

Listen for. Strong maps use actual words, identify a decision, and preserve unknowns. Partial maps describe only the intended process. Ask, 'What happened in this case?' A map that ends at referral needs a question about the next encounter, not an instruction to invent it.

Debrief. Ask one group to name the loss, then another for a different mechanism. Ask who has to do extra work because of it. Don't require every group to narrate its full case. Distinguish burden carried by the person, a worker's workaround, and an authorised organisational arrangement.

Fallback. Keep the same task in the main session, with private notes and two volunteer accounts. Don't spend the work time fixing breakout membership.

The idea. A worker may know what would help but lack time, information, a budget, a decision right, or protection when a target is challenged. A manager may hold one of these but not control the other organisations involved. 'Get the service lead involved' is the start of an inquiry into authority, not its conclusion.

Introduce the six conditions: boundary, demand, authority, capability, measurement, and sustainment. Use them as lenses from which to select one constraint. Don't give the group six simultaneous questions. Money, risk, and learning cut across them.

Worked example. Suppose the proposed change is to record whether a repair has actually been completed rather than whether a request was answered. The frontline worker may be able to capture the evidence. The service lead may be able to change the dashboard. A contract or corporate definition may sit elsewhere. Those authorities must be checked; they aren't facts established by the fictional case.

The 'strategy ceiling' is the point beyond which a necessary condition isn't open to discussion or revision. It may be a budget rule, a success measure, a contract, or an assumption about whose problem this is. Ask for the actual condition and evidence that it is held in place.

Don't make the centre a villain. Assurance about public money, equal treatment, lawful action, and safety remains necessary. Ask what assurance would make a different decision defensible, without simply recreating the same proxy measure.

Transition. 'Choose one condition your proposal needs to change. Build a route from what the person experiences to someone authorised to act on that evidence.'

Visible task. 'Design one arrangement that can change your limiting condition.' Output: one proposed learning loop, with a decision agreement and a bounded test. Continue with the same group and case.

Use the 13-minute work period for choosing one condition (4), drawing the loop (5), and recording a test (4). Reveal these stages in order; they don't require separate breakout visits. The work may remain incomplete. Preserve the unresolved permission rather than writing a fictitious agreement.

Worked pattern. Evidence from the person and the work → review involving the affected person and a role with authority → decision → changed response → feedback about the next encounter. Add a route for evidence that challenges the rule itself. A review meeting without a decision right is not yet this loop.

Decision agreement. '[Role] can decide [what] within [limits]. They provide assurance through [evidence and review]. Questions outside that authority go to [role or forum].' Mark each permission as agreed, proposed, or unknown.

Likely confusion. 'Create a dashboard' names a product, not how evidence changes a decision. Ask who acts differently when the dashboard changes. 'Give citizens the power to close every case' was a discussion proposal, not a universal rule: test rights, disagreement, safety, and the possibility that people don't respond.

Debrief. Ask, 'What decision can now change?' Then, after hearing the answer, ask what happens when the evidence challenges the rule. Keep a distinction between immediate repair, a protected exception, and changing ordinary arrangements.

The idea. One experiment tests whether a changed response helps the person. Another tests whether the organisation can authorise, resource, learn from, and retain that response. Success in the first doesn't establish success in the second.

Operational example. 'If repair appointments can fit working hours, we expect fewer failed visits and less disruption to work; we will examine completed repairs and the person's account.' This is a proposed hypothesis, not a result or a proven saving.

Institutional example. 'Ask the roles responsible for scheduling and performance reporting to authorise a limited test, agree an evidence review, and decide whether the booking and closure rules should change.' Establish the actual permissions, scope, support, and review date before starting.

Ask participants to record one conversation needed next. Test whether the arrangement would survive the helpful worker, sponsor, or special funding disappearing. Ask what their own map and proposal make less visible; the tool is also a selective representation.

Evidence. Look for the person's experience, practical outcomes, repeat contact, displaced work, unintended harm, and whether a decision or rule actually changed. Fewer contacts alone don't establish improvement. Stop or revise when the agreed safety boundary is crossed, burden is displaced, or necessary permission isn't available.

Follow-through. Participants own the next conversation. A sponsor or authorised role should own any decision about a real test. Record the intended review before closing; don't promise a follow-up that nobody has agreed to run.