In most SEO agencies between 5 and 30 people, one person writes (or reviews) every proposal. Usually the founder.
This works until it doesn't. At some point, the founder becomes the constraint — not because they're slow, but because every proposal requires their judgment on scope, pricing, exclusions, and positioning.
The math is simple: if proposals take 2–3 hours each and you send 8–10 per month, that's 16–30 hours of founder time. At $200/hour opportunity cost, that's $38K–$72K per year spent on a process that should be delegable.
This page covers why delegation fails, how to fix it, and when to move from process to system.
Who this is for
- Agency founders who are the bottleneck in their own proposal process
- Operations leads building scalable sales processes
- Senior team members being trained to write proposals
- Agencies growing from founder-led sales to team-led sales
Why delegation fails
Most agencies try to delegate proposals by giving a team member access to "the template folder" and saying "just follow the pattern." This fails because:
Invisible decisions
The founder makes dozens of micro-decisions when assembling a proposal — which sections to include, what hours to allocate, how to price, which exclusions to add. These decisions are invisible because they happen in the founder's head, not in a documented process.
Variability knowledge
"For enterprise clients, include the competitor analysis section" and "if they mention content, make sure to exclude writing unless it's explicitly in scope" — this knowledge only exists in experience.
No feedback loop
When delegation produces a bad proposal, the founder fixes it and moves on. The delegate doesn't learn why specific changes were made, so the same mistakes repeat.
The four-stage delegation framework
Stage 1: Document the decision logic (4–6 hours, one-time)
Before anyone else can assemble proposals, the logic needs to be visible:
| What to document | Example |
|---|---|
| What varies by engagement | Audit-only scopes don't include retainer sections |
| Pricing logic | Site size x engagement type x service mix = hours; hours x rate = fee |
| Inclusion/exclusion rules | If content writing is not included, add explicit exclusion |
| Guardrails | Minimum retainer: 3 months. Minimum monthly fee: $X. Never include link buying |
| Quality criteria | Every deliverable has quantity + completion trigger + exclusion |
This doesn't need to be perfect. It needs to be written down.
Stage 2: Create a structured intake process
Replace the blank page with a form. When the delegate starts a proposal, they shouldn't face a blank Google Doc — they should face a set of questions:
- Engagement type?
- Site size and platform?
- Services in scope?
- Content included?
- Local SEO?
- Budget range discussed?
Each answer narrows the scope. This removes the "where do I start?" problem.
Stage 3: Implement a review protocol that teaches
Don't just fix proposals — categorise corrections:
| Category | Example | Action |
|---|---|---|
| Critical | Missing exclusion that creates liability | Fix and document rule |
| Judgment | Pricing adjustment for client context | Discuss reasoning, no rule change |
| Style | Phrasing or formatting preference | Note preference, not a correction |
Over time, critical corrections become rules, judgment calls become guidelines, and style preferences become conventions.
Stage 4: Encode logic into a system
The progression:
- Written guide — documented rules and guidelines (Stage 1)
- Structured intake — form-driven assembly replacing blank page (Stage 2)
- Automatic assembly — system assembles from variables, human reviews (Stage 4)
Stage 4 is where RuleDox fits. The system handles the 80% that follows rules. The human handles the 20% that requires judgment.
The delegation quality test
A delegated proposal is acceptable when it's:
| Criteria | Test |
|---|---|
| Accurate | Deliverables match what was discussed. Pricing matches the rate card. Hours match the scope. |
| Complete | All required sections present. Exclusions included. Assumptions stated. |
| Defensible | If the client questions any element, there's a clear rationale. |
If a proposal passes all three, it's ready — even if the founder would have written it differently.
The founder time equation
| Metric | Before delegation | After system |
|---|---|---|
| Proposals per month | 8–10 | 8–10 |
| Founder hours per proposal | 2–3 hours | 15–30 minutes (review only) |
| Founder hours per month | 16–30 hours | 2–5 hours |
| Annual founder time | 200–360 hours | 25–60 hours |
| Annual opportunity cost (at $200/hr) | $40K–$72K | $5K–$12K |
The ROI of delegation isn't just time — it's capacity. When the founder isn't writing proposals, they're selling, managing, or building the business.
How RuleDox helps
RuleDox is the Stage 4 system. It encodes your scoping logic — engagement types, pricing rules, inclusion/exclusion conditions, hour calculations — into a rules engine that assembles scope documents in Google Docs.
- Team members select variables — engagement type, site size, services, content scope
- Rules determine scope — deliverables, exclusions, and hours populate automatically
- Pricing calculates from variables — no spreadsheet required
- Output is a Google Doc — ready for review, not recreation
- Founder reviews instead of writes — 15 minutes instead of 2 hours
FAQ
How long does it take to document the decision logic? 4–6 hours for a first pass. It doesn't need to be complete — start with the most common engagement types (audit, retainer, audit + implementation) and expand from there. Most founders find the exercise clarifying even before it enables delegation.
What if the delegate makes a pricing mistake? This is why Stage 3 matters. Categorise it (critical, judgment, or style), fix it, and add a rule to prevent recurrence. Pricing errors are almost always due to missing guardrails, not incompetence.
When should I move from documented process to system? When you're producing 8+ proposals per month and the documented process is stable (most proposals require minimal review corrections). If the process is still being refined, a system will encode the wrong logic.