Adoption
Orgo adoption is not “install software, hope for culture change.”
It is a reliability rollout : you replace fragile coordination (inboxes, chats, implicit ownership) with a system where work is routed, tracked, escalated, and closed.
The rollout in 4 phases
Phase 1 — Pilot
Choose a pilot that forces clarity
Pick one of these:
incident intake (service desk / emergency / operational issues)
procurement or approvals
citizen/client requests
compliance reporting
internal HR / staffing requests
Pilot rule: keep it boring
A pilot succeeds when it is:
small enough to run without a steering committeepainful enough that improvements are obviousmeasurable in closure time and missed work
Pilot deliverables (minimal)
5–10 functions (responsibilities)
10–20 routing rules (simple)
3 severity levels with response windows
1 escalation ladder per severity level
1 weekly review ritual
Phase 2 — Define functions, then route to them
Step 1: define “functions” (responsibilities)
A function is not a title. It is a duty the organization must perform reliably.
Examples:
Intake / triage
Incident response
Case management
Legal review
Procurement
Communications
Duty lead
Step 2: define routing triggers
Routing triggers can be:
topic/category (e.g., “procurement”, “incident”, “legal”)
location/team
severity
requester type (internal/external)
workflow stage
Step 3: define response windows + escalation
Set response windows that reflect reality:
urgent: minutes/hours
important: same day / next day
normal: a few days
Escalation should change ownership/scope, not just spam reminders.
Phase 3 — Install the review loops
Orgo becomes powerful when recurring problems stop being “background noise.”
Weekly review (operational)
overdue cases
repeated escalations
bottlenecks (functions overloaded)
quick wins (rules that reduce friction)
Monthly review (systemic)
patterns that require policy changes
recurring failure modes
“known issues” that need an audit case
Annual review (governance)
what escalation policy taught you
which functions need restructuring
what should be made public vs private (boundaries)
Phase 4 — Scale without breaking trust
Scaling Orgo isn’t about adding features. It’s about protecting these properties as you expand:
Auditability: outcomes remain traceable.Boundaries: private org work stays private; public interfaces remain deliberate.Governability: routing/escalation rules remain explicit and reviewable.Resilience: critical workflows keep operating in degraded conditions.
Adoption checklist
✓ You have a defined set of functions (owners by responsibility). ✓ You have response windows for at least 3 severity levels. ✓ You have an escalation ladder that changes scope/ownership. ✓ You have a weekly review ritual on the calendar. ✓ You have a simple “closure vocabulary” (resolved / rejected with reason / deferred with date). ✓ You know what metrics you will track (below). What to measure (so adoption isn’t subjective)
Median time from intake → closure, by severity.
How often cases are re-routed (signal that rules need refinement).
Overdue cases and escalations by function (signal of capacity bottlenecks).
Common failure modes (and fixes)
Too many categories early → Start with 10–20 routing rules; refine after real traffic.Escalation feels punitive → Make escalation a safety system with clear thresholds and transparent ladders.People keep using chat → Treat chat as discussion; require cases for anything that needs ownership/closure.Review meetings become status theater → Reviews must output new cases, rule changes, or capacity decisions.
Next
