Name the decision, not just the task
“Own the client” or “manage the project” is too broad to delegate safely. Classify the decisions that interrupt work:
| Decision class | The question to answer |
|---|---|
| Routine coordination | Which changes are already within an agreed service boundary? |
| Bounded judgment | Which trade-offs may the delegate make, and within what limit? |
| Commitment | Who may change price, scope, promised date, or client obligation? |
| High-consequence exception | Who may pause work for safety, privacy, security, or material delivery risk? |
| Recovery | Who corrects a bad decision and informs the affected people? |
A task can be assigned while every one of these decisions remains founder-only. That is useful information. Do not conceal it with a status label.
Build a decision-rights register
Start with the evidence packet's representative register. For each recurring decision, name the delegated owner, authority limit, retained evidence, founder escalation trigger, client communication owner, and recovery action. A delegate does not need permission to do every related task; they need a clear boundary for the decision they own.
Separate a boundary from a handoff
A handoff says who acts next. A boundary says when that person is allowed to act. For a routine scheduling change, the coordinator might confirm an existing agreed window. A change that promises an earlier date or additional work might escalate to an account lead. A commercial commitment might remain with a named authorised owner.
Without this separation, people either wait unnecessarily or make commitments they were never meant to make.
Make escalation change the next action
“Ask the founder” is not an escalation design. An escalation needs a trigger, recipient, expected decision, client communication owner, and recovery path. For example, a scope ambiguity could require the account lead to choose among three recorded options rather than simply forward the original message.
Keep the trigger observable: a proposed promise outside the agreed window, an unapproved cost, a missing client authority, or a privacy concern. “Use judgment” is not a testable escalation threshold.
Walk ten real decisions before configuring software
Trace ten recent decisions, including one reversal and one client escalation. For each, replace the representative register with the real actor, time, evidence, authority limit, and recovery. Look for decisions made in private messages, meetings, or memory.
If the same founder receives the same question repeatedly, the next improvement may be a written boundary or a narrow handoff aid. It is not automatically a CRM field, workflow rule, or custom portal.
Acceptance rule
Use a tool only after every consequential decision has a named owner, authority limit, evidence record, escalation recipient, client path, and correction method. Keep the representative map visible as a draft until a service operations owner validates it against real decisions.