Case documents

Situation

A fictional membership service receives requests through a shared inbox. The front desk acknowledges a message, while a specialist team decides what happens next. The example procedures describe both activities but do not name a single acceptance event.

Evidence available

The supplied teaching pack contains an acknowledgment template, a front-desk checklist and a specialist intake form. The checklist says “forward to the relevant team.” The intake form requires a request type and a named contact, neither of which appears in the forwarding instruction.

The open question

What observable action means the receiving team has accepted responsibility, and who follows up when that action does not occur?

Proposed approach

Trace one example request from arrival to an explicit next step. Put the two procedures beside the actual information each role needs. Ask the receiving role to describe acceptance in a way the sending role can see. Separate “message delivered” from “work accepted”; those are different events.

The first conversation should distinguish a change in responsibility from a change in communication channel. Moving a request into a different inbox does not, by itself, explain who must decide whether the request is complete. A useful acceptance signal could be explicit, but its form should fit the service’s existing tools and constraints.

The eventual agreement should also name an exception route. A request that lacks information may need clarification, rather than silent rejection or indefinite holding. The proposed deliverable makes those questions visible without prescribing a tool or claiming the process is already understood.

Proposed deliverable

A handoff agreement identifying the entry condition, required information, acceptance signal, exception owner and next review point. Include a worked example and a short list of unresolved operational questions.

Before proceeding

Review a small, appropriately redacted set of actual handoffs with both roles before recommending a new agreement.

Situation

In a fictional small product team, a weekly review considers requests for changes to an existing service. The written agenda invites delivery, customer-support and product roles to agree a priority. It does not say what happens when they cannot agree.

Evidence available

The teaching pack includes a meeting agenda and a decision-log template. The agenda names three contributing roles. The log has fields for the topic and next action, but no field for decision owner, rationale or the conditions under which a decision should be revisited.

The open question

Which role holds the decision, what input must they consider, and what conditions require escalation rather than another open discussion?

Proposed approach

Choose one recurring decision type rather than mapping the whole organization. Describe its boundaries, relevant constraints and consequences. Ask each role what contribution it makes and what it needs to know afterward. Test the proposed authority model against a disagreement scenario.

A lightweight decision record should capture enough reasoning for someone outside the meeting to understand what was chosen and why. It should not turn every small choice into a committee process. The scope is one repeatable decision with a known set of contributors.

A revisit condition is useful when a decision rests on an assumption. Recording that condition avoids treating a provisional choice as permanent, while also avoiding endless reopening without new information. The consultancy’s role is to clarify the model; the organization retains the authority to adopt it.

Proposed deliverable

A decision-rights note with a named role, required inputs, escalation conditions and a concise decision record. Include a disagreement example and a revisit condition.

Before proceeding

Confirm the decision owner and escalation route with the people who actually hold authority before using the note.

Situation

A fictional shared workshop provides new members with a welcome email and a long handbook. The email links to the handbook’s first page. A newcomer wants to know how to arrange an introductory orientation, but the relevant instruction sits inside a section titled “Membership administration.”

Evidence available

The authored example includes the welcome email’s link label, the handbook contents and a short orientation instruction. The contents are organized by the operator’s departments rather than by a newcomer’s questions. No real user behavior is supplied.

The open question

Can a newcomer identify the first required action, its prerequisites and the person to contact when they cannot complete it?

Proposed approach

Choose the first task and list the information required to attempt it. Compare that list with the welcome email and handbook navigation. Ask whether the language describes the newcomer’s goal. Plan a small comprehension check with intended readers before replacing the whole handbook.

The first-task sequence should answer “What should I do?”, “What do I need?” and “What happens next?” It can be short while still linking to the full policy material. The purpose is orientation, not the removal of necessary detail.

Content ownership matters after the rewrite. If the orientation process changes, somebody must know which message and handbook section need updating. The proposed deliverable therefore includes an owner and a review trigger, not only a new welcome paragraph.

Proposed deliverable

A first-task welcome sequence, an information hierarchy and a content test plan. Keep policy detail accessible through descriptive links instead of duplicating it.

Before proceeding

Check the proposed task language with intended newcomers and confirm that operational prerequisites are accurate.

Situation

A fictional event organization publishes visitor guidance on a website, in a PDF and in an internal response template. The editorial team can change the website, while operations maintains the PDF. Neither document explains which source should lead when wording differs.

Evidence available

The teaching example contains three different descriptions of when a visitor should contact the organization about an access request. The examples are deliberately inconsistent. They demonstrate duplication; they do not document an actual organization or access policy.

The open question

Where is the authoritative information maintained, who can approve a change, and how are dependent copies identified and updated?

Proposed approach

Inventory one information topic across its published and internal forms. Separate the owner of the underlying policy from the editor of each channel. Identify the event that should trigger review, then test how a proposed change travels to every dependent copy.

An ownership map is useful only if it names a practical maintenance path. The person editing a web page may need an approved policy statement from another role; the person responsible for the policy may not control the publishing system. That distinction should be explicit.

A change checklist should follow the dependencies of the information rather than the structure of a department chart. Start with one topic, test the path and adjust it. Expanding the model to every document before validating the first topic would create a register without a reliable maintenance practice.

Proposed deliverable

An information-ownership map, source-of-truth rule and change checklist for one topic. Include a small dependency diagram and an unresolved-questions register.

Before proceeding

Confirm the policy owner, editorial owner and dependent channels before migrating or deleting any live guidance.