Published August 12, 2026
A delegation service level agreement records response windows, priority levels, and exception handling for recurring support work. The goal is not to move work away from a founder without thought. It is to make ownership, context, and evidence clear enough that the work can move with appropriate review.
Start with a defined outcome
Before assigning the work, write the outcome in one sentence. A useful outcome names what should exist when the task is complete, who will use it, and what would make it unacceptable. “Handle this” is not an outcome. “Return a reviewed shortlist with sources, tradeoffs, and a recommendation for the next decision” is.
This distinction matters because the owner needs room to choose a method. A handoff that specifies every click can be difficult to adapt, while a handoff that specifies only a vague result creates rework. The right brief sets the boundary and leaves ordinary execution with the person doing the work.
Put context where the owner can use it
Record the inputs that change the answer: audience, deadline, priority, systems, known constraints, and examples of acceptable work. Include links to the source documents rather than assuming the owner can reconstruct the background from old conversations.
An effective brief also states what is out of scope. For example, a research task may allow comparison of public information but not a purchase, a promise to a vendor, or a change to an account. Clear boundaries prevent a well-intentioned assistant from making a decision that belongs elsewhere. The broader principles in how to delegate effectively help connect those boundaries to a repeatable handoff.
Use a small control table
| Field | What to record | Review question |
|---|---|---|
| Outcome | The finished result and user | Is success observable? |
| Inputs | Files, links, access, and assumptions | Can the owner begin without searching for context? |
| Authority | Decisions the owner may make | Are approval limits explicit? |
| Evidence | Checklist, source list, or saved output | Can completion be checked quickly? |
| Exception | Cases that pause or escalate the work | Does the owner know when not to proceed? |
This table is intentionally compact. Too many fields can turn a brief into a form that no one maintains. Add a field only when it prevents a recurring mistake or removes a meaningful ambiguity.
Set a useful review loop
The first review should look for calibration, not perfection. Compare the result with the stated outcome, identify the exact decision that went differently, and update the brief if the standard was unclear. If the same correction appears twice, it belongs in the process or reference material rather than in another private reminder.
Use evidence that matches the task. A completed calendar invitation, a source-backed comparison, a checked article, or a concise exception note is more useful than a generic “done.” Keep review timing proportional to risk. Routine work may need a sample review, while a sensitive or irreversible action needs approval before it happens.
Keep editorial work distinct and reviewable
For article and SEO routines, the owner should preserve the page purpose, source trail, internal-link rationale, metadata, and asset state. A publishing queue should show whether an item is briefed, drafted, checked, or ready. daily article creation routine gives the daily routine a place to record the next action. The authoritative reference for crawlable links and people-first content is Google Search Central's SEO Starter Guide.
Do not use a publishing deadline to excuse an unresolved claim, duplicate page purpose, missing asset, or unclear escalation. A visible exception is progress because it gives the next owner a precise action.
Review and improve the handoff
At the end of the cycle, record what was easy, what required clarification, what was corrected, and what should change before the next run. This is the difference between delegating a task and building a reliable operating system. The handoff becomes more valuable as it captures real decisions without turning every edge case into a new rule.
Frequently asked questions
How much detail should a first brief contain?
Enough to define the outcome, inputs, authority, evidence, and escalation path. Start with one real example and add detail when a real case exposes a gap.
Should every delegated task require approval?
No. Approval should follow consequence and reversibility. Let the owner complete bounded, reversible work independently, and route decisions involving money, commitments, sensitive access, or strategic judgment.
What if the owner asks a question every time?
Look for a missing rule, missing context, or unclear authority. Answer the immediate question, then update the brief if the same situation is likely to recur.
How do I know the process is ready to expand?
Look for consistent outcomes, fewer clarification requests, timely evidence, and exceptions that are handled through the agreed path. Expand scope gradually and keep the review loop active.
Sources
- Google Search Central: SEO Starter Guide. https://developers.google.com/search/docs/fundamentals/seo-starter-guide