---
name: 01-pipeline-review
description: Run when I paste the pipeline. Trigger - \"run 01\" plus the pipeline.
---

# TASK 01 — PIPELINE REVIEW

## INPUT
Deals with stage, value, sector, go-live or contract date.
Better: next step, owner, and last week's version.

## PROCESS
1. Rank by value x closeability before its date. Anything
   without a next step older than 30 days is excluded from
   the top three.
2. Compare to last week. Flag slips, never scold.
3. Read sector mix against [SPLIT]; say plainly if the
   pipeline is not pointing where the plan says.
4. Flag renewal risk where a customer could be shopping a
   direct single-provider quote — name the accounts.

## OUTPUT
PUSH THIS WEEK (3: account, value, action, owner, date) /
SLIPPED (1 line each) / MIX (2 lines) / DIRECT-QUOTE RISK
(accounts, 1 line each).

## RULES
- One screen. Never estimate a value not in the paste.
- A deal without a contract or go-live date ranks below one
  with a date, whatever the size.

## EDGE CASES
- No sector tags: rank anyway, say the mix read needs tags.
- All healthy: say so, then name the one renewal you would
  still worry about and why.

## GOOD LOOKS LIKE
\"DIRECT-QUOTE RISK: the two marine accounts renewing Q4.
Both have had a clean quarter — which is exactly when the
cheap direct quote looks best.\"

---
name: 02-bid-response
description: Run when a tender, RFP or bid request lands. Trigger - \"run 02\" plus the requirement and what I gave you.
---

# TASK 02 — BID RESPONSE

## INPUT
The requirement or tender substance: sites, uptime need,
timeline, evaluation criteria. Plus what I told you we can
commit.

## PROCESS
1. Read back their operational need in their words, one
   line. Wrong read-back loses bids before pricing does.
2. Sketch the multi-path approach in three lines from what I
   gave you — constellation-agnostic, one managed service,
   24/7 operations.
3. Every contractual number — SLA, uptime, response time —
   comes from [SLA DOCS] or appears as [SLA] flagged to me.
4. Three questions that shape the solution, answerable with
   information. Close with the next step, dated.

## OUTPUT
The response core (read-back, approach, questions, next
step) + INTERNAL: every [FLAG] that needs a real number
before submission.

## RULES
- Never invent an SLA, a coverage map claim, or a deployment
  timeline someone else must deliver.
- Same-day acknowledgment beats complete. A sharp read-back
  with three good questions buys the time the full bid
  needs.

## EDGE CASES
- The tender is written around a single named provider:
  answer the outcome, not the brand — and ask the question
  that reopens the spec: what happens to the requirement on
  that provider's worst day?
- Evaluation is price-only: say so to me. We do not win
  price-only paper, and pretending costs credibility.

## GOOD LOOKS LIKE
\"READ-BACK: forty remote sites, works cannot stop when a
link drops, service credits matter less than restoration
time. Confirm before anything else travels.\"

---
name: 03-single-provider-reply
description: Run when a buyer or customer compares us to buying a single provider direct. Trigger - \"run 03\" plus what they said.
---

# TASK 03 — SINGLE-PROVIDER REPLY

## INPUT
Their pushback, verbatim if possible. Their sites and what
downtime costs them if I told you. Renewal or new business.

## PROCESS
1. Diagnose, one line to me: price comparison, genuine fit
   question, or negotiation ritual.
2. Concede completely what is true: direct is cheaper,
   installs fast, works well most days. Fighting facts
   loses.
3. Change the unit: they priced a link, we sell continuity.
   One constellation is one failure domain — one congestion
   profile, one outage calendar, one roadmap they don't
   control.
4. Hand them the test they can run without trusting us:
   90 days of their own incident minutes, priced against
   their own cost of downtime.
5. If their number is genuinely small: tell them to buy
   direct, warmly, and book the review for next quarter.

## OUTPUT
- One line to me: the diagnosis.
- The reply (OUTPUT DEFAULTS apply).
- THE RESERVE: the line for a zero-incident pilot — held
  back, not sent.

## RULES
- Never a bad word about the provider they priced. Ever.
- No uptime or SLA claims not in [SLA DOCS].
- Never argue with a good experience. Schedule the follow-up
  for when the experience changes.

## EDGE CASES
- It is a renewal and they have already signed direct: make
  leaving easy, leave the door open, calendar the check-in.
- Their downtime genuinely costs little: say so to me — this
  is a fit question, and the honest answer wins the next
  site.

## GOOD LOOKS LIKE
\"If that number is small, go direct and you'll get no
argument from me. If it isn't, that gap is what you're
paying us for.\"

---
name: 04-price-pushback
description: Run when a buyer pushes on price. Trigger - \"run 04\" plus their pushback and my floor if I have one.
---

# TASK 04 — PRICE PUSHBACK

## INPUT
Their pushback, verbatim. What they are comparing us to. My
floor if I gave one. Term, sites, scope.

## PROCESS
1. Diagnose: budget ceiling, ritual, or a comparison
   mismatch — a bare link priced against a managed
   multi-path service is a category error, and most
   pushback here is exactly that.
2. If mismatch: run task 03 logic instead of discounting.
3. Otherwise hold with ONE reason tied to something concrete
   — the operations team, restoration time, the field
   engineering.
4. Concede one thing that is not price, only from what I
   said exists: term shape, phased rollout, billing timing.
5. Write the walk-away, polite, held in reserve.

## OUTPUT
Diagnosis (1 line to me) / the reply / THE RESERVE, marked
\"only if they push again\".

## RULES
- A given floor is absolute. No floor given: ask BEFORE
  drafting. Hard stop.
- Never match a price not seen in writing.
- Never buy a deal with an SLA we have not costed.

## EDGE CASES
- Procurement pushing after operations already agreed value:
  the reply arms the operational champion; it does not
  negotiate with procurement in writing.
- Multi-year ask for a discount: trade term for price only
  at [AUTHORITY] and say so to me first.

## GOOD LOOKS LIKE
\"Diagnosis: category error — they are pricing one link
against a managed service with a 24/7 desk. The reply asks
what their quote includes at 2am.\"

---
name: 05-partner-meeting-prep
description: Run before a channel partner or reseller meeting. Trigger - \"run 05\" plus who, history, and what I want.
---

# TASK 05 — PARTNER MEETING PREP

## INPUT
The partner, who I am meeting, trading history if I gave it,
what I want from the room.

## PROCESS
1. Compress their situation from ONLY what I gave you;
   anything inferred is marked \"guess:\".
2. My objective as one sentence with a number or date in it.
3. Three questions that surface THEIR economics — where they
   make margin, what their customers escalate, which deals
   they lose and to what.
4. Two likely objections with one-line answers. One is
   always channel conflict — do we sell around partners? The
   answer is the rule, stated plainly.
5. The close: what I ask for before leaving.

## OUTPUT — one page
THEIR SITUATION / MY OBJECTIVE / THREE QUESTIONS /
TWO OBJECTIONS + ANSWERS / THE CLOSE.

## RULES
- A partner meeting is about their P&L, not our deck.
- Never promise pricing, exclusivity or leads outside
  [AUTHORITY].
- Nothing generic: every question unusable for another
  partner without editing.

## EDGE CASES
- A partner we have disappointed before: the prep names it
  in line one and the meeting opens with it. Skipping it is
  the only fatal move.
- Prospective partner who also resells a single provider:
  fine — position multi-path as their upsell, never as a
  replacement of what they already earn on.

## GOOD LOOKS LIKE
\"Q1: On the deals you lost last quarter, what did the
winner have that your bid didn't — price, coverage, or an
operations story?\"

---
name: 06-outage-postmortem
description: Run after a service incident when the customer email is due. Trigger - \"run 06\" plus the timeline and facts as established.
---

# TASK 06 — OUTAGE POSTMORTEM

## INPUT
The incident timeline as established, root cause if known,
what restored service, what changes as a result, and any
commercial remedy I have authorised.

## PROCESS
1. Line one: what happened and for how long, in plain
   figures. No wind-up, no \"we take reliability seriously\".
2. Timeline: detected, acted, restored — times only from
   what I gave you.
3. Cause stated honestly. If a provider failed upstream,
   name the category, never rubbish the brand: \"an upstream
   constellation outage\" is a fact, not an attack.
4. What changes, with a date. A postmortem without a change
   is an apology.
5. Remedy only if I authorised one. Never invent credits.

## OUTPUT — one email, 150 words max
WHAT HAPPENED / TIMELINE / CAUSE / WHAT CHANGES (dated) /
REMEDY (only if given). Subject plain, never \"Service
Update\".

## RULES
- Facts I did not give you do not appear. An unknown cause
  is stated as under investigation with a date for the
  answer.
- The customer's downtime cost is never minimised.
- Same length whether the outage was ours or upstream. The
  temptation to write more when it wasn't our fault is the
  tell.

## EDGE CASES
- Cause unknown at send time: commit to the follow-up date
  and keep it.
- The customer is contractually owed credits: state them
  without being asked. Paying before being chased is worth
  more than the credit costs.

## GOOD LOOKS LIKE
\"WHAT CHANGES: that site moves to dual-path by Fri 19 Sep,
so a repeat of Tuesday's upstream failure would have been a
switchover measured in seconds, not an outage measured in
hours.\"

---
name: 07-week-plan
description: Run Sunday night or Monday morning. Trigger - \"run 07\" plus calendar, live deals, anything on fire. Reads on a phone.
---

# TASK 07 — WEEK PLAN

## INPUT
Calendar, live deals and bids, partner matters, team
matters, anything on fire.

## PROCESS
1. Three OUTCOMES, one each: direct revenue, channel, team.
   If one lane has nothing, name it and say why that is the
   risk.
2. What to decline or delegate, with the one-line script.
3. The thing I am avoiding — in a new seat it is usually a
   relationship not yet opened or a legacy account not yet
   visited, not a deal.

## OUTPUT — half a page, phone-readable
THREE OUTCOMES (direct / channel / team) / DECLINE OR
DELEGATE / THE AVOIDED THING (one line).

## RULES
- Outcomes state what is TRUE on Friday.
- Maximum three; say what you parked.
- First quarter in the seat: an external meeting outranks an
  internal one in a collision, and say so when they collide.

## EDGE CASES
- Bid-deadline week: everything else compresses to holding,
  stated plainly, with the date it ends.
- All-internal week: the first outcome becomes carving
  external time, with the two meetings to move named.

## GOOD LOOKS LIKE
\"AVOIDING: the legacy account that predates you. Every week
you don't visit, the incumbent story about the new CRO gets
written by someone else.\"

---
name: 08-ceo-one-pager
description: Run at month end for the CEO. Trigger - \"run 08\" plus the month's numbers and anything he should hear from me first.
---

# TASK 08 — CEO ONE-PAGER

## INPUT
Revenue vs plan, pipeline, wins and losses with values,
renewals, partner movements, team changes, anything the CEO
should hear from me before anyone else.

## PROCESS
1. Line one is the number vs plan. No wind-up.
2. Three wins with values, tagged direct or channel. Two
   losses with the honest reason — price, process, coverage,
   or relationship. Never merged into \"competitive
   pressure\".
3. Renewals and churn risk in two lines, accounts named.
4. Team in one line, only if something moved.
5. The ONE decision or support I need, dated.

## OUTPUT — one page, in this order
THE NUMBER / WINS (3) / LOSSES (2) / RENEWALS (2 lines) /
TEAM (optional) / THE ASK (dated).

## RULES
- No adjective a number could replace.
- Losses name the reason, never the seller.
- A bad month gets the same structure and length. Writing
  more is the tell.

## EDGE CASES
- A win or loss driven by an upstream provider's event: say
  so plainly. Taking credit or assigning blame for weather
  costs the next conversation.
- No ask: \"No decision needed this month.\" Never invent
  one.

## GOOD LOOKS LIKE
\"LOST: £180k energy tender — spec was written around a
single named provider and price-only scoring. Process, not
product. We asked the worst-day question; it reopens in Q2.\"