tss-proposal

A proposal is not a pitch. It's a mirror held up to the client's problem.

If they read it and think "yes, that's exactly what's broken" — the proposal did its job before they saw a single price.

---

Prerequisites — Do Not Produce Without These

Input	Source
Real problem named	tss-sight output
Phase map defined	tss-scope output
Deliverables named	tss-scope Scope Map
Client inputs identified	tss-scope output
Decision maker confirmed	Diagnostic conversation

If any input is missing: Run the prerequisite first. A proposal without a scope is a guess with a price tag.

---

Proposal Structure

01 — What we heard     (problem in their language — not our pitch)
02 — What we found     (diagnostic observation — the real problem)
03 — What we'd do      (phase map with rationale)
04 — What you get      (named deliverables per phase — not activities)
05 — What we need      (client inputs required, and when)
06 — What's not in scope (explicit boundary — silence is not exclusion)
07 — Investment        (3 options: Entry / Recommended / Partnership)
08 — Next step         (one action, one date)

---

Investment Options — 3 Always

Never present one price. Never present two.

Option	Scope principle	Framing
Entry	Minimum scope to answer the core question — side:sight + side:scope only	Diagnosis before full commitment
Recommended	Optimal scope — foundation built and verified	Through side:setup, system ready to run
Partnership	Long-term embedded model — all 5 phases, ongoing side:sync	Shared risk, shared growth

Pricing rules:

• Price by depth of partnership, not by hours
• Each option shows outcome first, not effort
• "Entry" is not a discount — it's a smaller scope
• "Partnership" commands the highest rate — it carries the most risk

---

Writing the Investment Section

INVESTMENT

[Option 1: Entry]
→ Phases: side:sight + side:scope
→ Deliverables: Situation Report, Priority Matrix, Scope Map
→ Duration: [X weeks]
→ Investment: [Price]
→ For companies that need a diagnosis before committing to a full engagement

[Option 2: Recommended]
→ Phases: side:scope + side:setup [+ side:scale if applicable]
→ Deliverables: [Named list]
→ Duration: [X weeks]
→ Investment: [Price]
→ For companies ready to build the system, not just name the problem

[Option 3: Partnership]
→ Phases: Full 5S sequence
→ Deliverables: [Named list] + ongoing side:sync
→ Duration: [Initial X weeks + ongoing partnership]
→ Investment: [Monthly retainer + setup fee]
→ For companies that want The Side System™ embedded, not just engaged

---

Deliverable Naming Standard

Every deliverable in the proposal must be named as an output, not an activity.

❌ Activity	✅ Output
Strategic sessions	Situation Report
Workshop with leadership team	Priority Matrix + Decision Map
Implementation support	Working [system name] infrastructure
Ongoing advisory	Monthly side:sync session + progress report

---

Copy Rules for Proposals

• Open with what we heard — not who we are
• Never: "We'd love to work with you"
• Never: "Looking forward to hearing from you"
• CTA: "Reply with your preferred option by [date]"
• Investment section uses "investment" not "cost" or "price"
• Every exclusion must be explicit ("this does not include X")

---

Difficult Conversations — Built Into the Proposal

Address friction before it appears:

Budget concern:

A smaller investment is available for a smaller scope. The Entry option delivers a full diagnosis — and that alone changes how you make the next decision.

Timeline concern:

The timeline reflects what the work actually requires. Half the time means half the scope or double the resource cost — which direction works for you?

Scope concern:

What's not in scope is listed explicitly. Anything not on that list is available in a separate engagement.

---

Red Flag Check — Before Sending

Signal	What to do
Scope was discussed verbally but not documented	Stop. Write the scope first.
Client has multiple decision makers with no alignment	Name the approval process in the proposal
Timeline was set by the client	Reframe in the proposal or flag it as a constraint
Client resists side:sight	Address it directly in Section 02
No clear success metric	Define it in Section 04 as part of deliverables

---

Post-Proposal Protocol

Proposal sent
     ↓
Wait [X days for response — agree on this upfront]
     ↓
Follow-up: "The proposal is attached. One note before you read it: [key observation]"
     ↓
Response: negotiate scope, not price
     ↓
Agreement → `/client-update` → `bb-ops-linear`

---

Handoff

After tss-proposal	Next
Proposal accepted, kick-off needed	→ bb-client-comms + bb-ops-linear
Proposal needs copy review	→ tss-copy
Proposal needs deck formatting	→ tss-deck