When 988 and 911 connect well, callers experience a single, coherent system. When they connect poorly, the transfer becomes the crisis: delays, repeat storytelling, unnecessary law enforcement dispatch, or an avoidable ED pathway. This article sets out how providers and system leaders design defensible transfer agreements that make decision rights explicit, define what information must move, and create accountability after the call. For related operational context, see the 988–911 crisis routing and interfaces hub and the broader crisis response models series.
Why “transfer agreements” are operational safety tools, not paperwork
A 988–911 interface is a live operational boundary between two high-liability environments with different missions, training models, technology stacks, and response options. A transfer agreement is the mechanism that prevents that boundary from becoming a gap. In practice, the agreement must do three things: (1) assign decision rights (who has authority to request 911 dispatch, who can decline, who can reroute), (2) define the minimum information set required to make a safe decision, and (3) establish a closed-loop accountability process so repeat failures trigger correction rather than normalization.
Funders and oversight bodies increasingly expect proof that handoffs are governed, not improvised: documented protocols, measurable performance (answer times, transfer success, warm handoff rates), and an incident-learning process for sentinel events, complaints, and repeat callers. In parallel, privacy and consent expectations require systems to define when disclosures are permitted, how “minimum necessary” is operationalized, and how documentation supports defensibility without creating barriers to response.
Designing decision rights that reduce both under-response and over-response
Decision rights are the core of a workable agreement. They prevent two common failure modes: (a) escalation inertia, where staff transfer “just in case” because they are unsure what they are allowed to do, and (b) dangerous hesitation, where staff delay because they fear liability for the “wrong” choice. A defensible model typically includes: clear triggers for 911 involvement, explicit authority for 988 to initiate mobile crisis dispatch without 911 when appropriate, escalation paths to clinical supervisors, and a defined process when 911 believes a call should be returned to 988 for continued stabilization.
To make this real, systems often need a joint escalation matrix that translates risk into response options that actually exist locally (mobile crisis availability, co-responder coverage, crisis receiving centers, peer warmline alternatives, after-hours on-call clinical support). A matrix that names resources that do not exist in practice is worse than useless: it drives misrouting, angry responders, and “default to ED” behaviors.
Operational Example 1: A scripted “decision rights” transfer pathway for ambiguous risk
What happens in day-to-day delivery: A 988 counselor identifies escalating risk but incomplete location details and no immediate evidence of a weapon. The protocol requires a rapid supervisor huddle (30–60 seconds) and a scripted transfer to 911 that starts with a single sentence: “This is a request for welfare check with clinical risk context; dispatch decision remains with PSAP; we will stay on the line for a warm handoff.” The counselor then delivers the minimum data set (identity details if known, callback number, best-known location logic, observed risk indicators, known disabilities/communication needs, and any safety considerations), while the supervisor documents the rationale and timestamps the transfer steps.
Why the practice exists (failure mode it addresses): Ambiguous cases are where systems fragment. Without shared decision rights, 988 may over-transfer to avoid blame, or delay while trying to “perfect” the assessment. The practice is designed to prevent two breakdowns: delayed dispatch due to uncertainty, and miscommunication that leads to the wrong response type (e.g., law enforcement only when a clinical co-response is available).
What goes wrong if it is absent: Staff either transfer too early with poor information (“caller is suicidal, unknown location”), producing ineffective dispatch, or they hold the call too long, increasing the chance the caller disconnects. 911 may receive insufficient context, dispatch a default response, and then discover key facts on scene (autism, sensory needs, prior trauma with police) that increase the risk of escalation. Documentation becomes vague, making the system unable to learn or defend decisions afterward.
What observable outcome it produces: You can audit transfer timeliness, completeness of handoff fields, and whether the dispatch decision aligns with the escalation matrix. Over time, systems should see fewer “bounce-back” transfers, fewer calls abandoned during transfer, reduced duplicate dispatch attempts, and clearer post-incident review outcomes because decision rationale is documented in a structured way.
Defining the minimum data set: “enough to act” without over-collection
Minimum data sets are where agreements often fail: either they are too thin to support safe dispatch, or they become unrealistic “everything we might want” lists that staff cannot complete in real time. A defensible minimum set typically includes (1) contact and location logic (not just an address, but how that address was determined), (2) immediate risk indicators and time horizon, (3) any known medical/behavioral factors that affect response safety, (4) known weapons access indicators if disclosed, and (5) the caller’s preferred communication approach if known.
Oversight expectations usually require that systems show how privacy rules are operationalized during crises: role-based access, minimum necessary sharing, and documentation that distinguishes observed facts from third-party reports. Agreements should also specify what happens when the caller withholds consent: what can still be shared for safety, what must be withheld, and how staff record the decision without freezing response.
Operational Example 2: A “location uncertainty” protocol with callback control and dispatch handshakes
What happens in day-to-day delivery: A caller disconnects mid-transfer, leaving partial location clues (county mentioned, nearby landmark, phone number). The agreement triggers a location uncertainty workflow: 988 retains “callback control” for a defined window (e.g., first 5–10 minutes), attempts recontact, and updates a shared dispatch note with any new location logic. 911 agrees to acknowledge receipt of updates and confirm whether a unit is being dispatched, staged, or held pending location confirmation. A single identifier is used across both systems so updates attach to the correct incident.
Why the practice exists (failure mode it addresses): Location uncertainty creates the highest-risk handoff errors: duplicate incidents, dispatch to the wrong jurisdiction, or no dispatch because each side believes the other has it. The workflow exists to prevent “silent failure” by making ownership explicit and updates structured.
What goes wrong if it is absent: Two separate incidents may be created, leading to parallel responses that confuse responders and increase liability. Alternatively, neither system dispatches promptly because each is waiting for better information. Staff may also share unverified details without labeling them as uncertain, causing misrouting or unsafe scene approaches.
What observable outcome it produces: Systems can track time-to-dispatch under uncertainty, number of duplicate incidents, and the proportion of uncertainty cases resolved through structured callbacks versus escalation. A mature system shows fewer “no unit ever dispatched” reviews and better jurisdiction accuracy.
Accountability after the call: the agreement must include learning and enforcement
Transfer agreements that do not specify post-incident governance will drift. At minimum, agreements should define: which body owns QA across the interface (joint committee with authority), what triggers mandatory review (deaths, serious injuries, repeat misroutes, complaints), how recordings and documentation are shared for review, and what corrective actions look like (training refresh, scripting changes, routing table updates, staffing changes, technology fixes). Funders commonly expect evidence of corrective action, not just meeting minutes.
Critically, governance must treat repeated interface failures as system defects, not individual blame. If staff are punished for escalating “incorrectly,” escalation becomes defensive and outcomes worsen. Defensible governance instead focuses on clarity of decision rights, realism of protocols, and measurable improvement.
Operational Example 3: A joint QA loop that turns transfer failures into redesign
What happens in day-to-day delivery: The system flags a cluster of cases where 988 transferred to 911, 911 dispatched law enforcement only, and the calls returned to 988 after no contact. A joint QA reviewer pulls a standard packet: call recordings (where permissible), structured handoff fields, dispatch timestamps, and outcome notes. The review meeting uses a fixed agenda: identify failure point, assess whether protocol was followed, decide whether protocol is wrong or training is insufficient, assign an owner, and set a 30-day verification check (audit 20 similar calls for improvement).
Why the practice exists (failure mode it addresses): Without a joint QA loop, each side explains failures as “the other side’s problem.” The practice exists to prevent normalization of defects and to ensure that patterns (not just individual incidents) drive redesign of routing rules, scripts, and escalation matrices.
What goes wrong if it is absent: Interface failures recur, staff confidence declines, and escalation becomes either overused or avoided. The system accumulates “repeat callers” who are actually repeat system failures. Oversight scrutiny increases because the system cannot demonstrate learning, only volume and anecdotes.
What observable outcome it produces: Over time, you should see measurable reductions in repeat transfer loops, improved first-time resolution, fewer complaints tied to “bounced between numbers,” and stronger documentation quality. The key evidence is not perfection; it is disciplined detection and correction.
Implementation checklist: what must be true for the agreement to work
- Decision rights are written in plain language and trained with live call scenarios.
- A minimum data set is short enough to be deliverable under pressure and structured enough to be auditable.
- Location uncertainty and disconnection workflows assign ownership and enable updates without chaos.
- QA governance has authority to change scripts, routing rules, staffing patterns, and training requirements.
- Privacy and consent are operationalized as “what we do,” not just legal references.