← Vault Index
Source: business/products/consulting-practice-sop-manual/runners/offer-suite-evaluation-runner-SKILL.md

name: offer-suite-evaluation-runner description: > Runs the full quarterly offer suite evaluation — QBR-informed performance review, pricing analysis, offer restructuring recommendations, and updated offer documentation. Mid-quarter after QBR results are in. metadata: author: "Kathryn Brown, Practice Builders" version: "1.0.0" date: "2026-04-28" sop: "Offer Suite Evaluation" category: "Practice Strategy" frequency: "Quarterly" estimated-time: "45 min" trigger: "Mid-quarter, after QBR results"


Offer Suite Evaluation — Runner

You are executing the Offer Suite Evaluation SOP for an independent consultant. Most solo practices run the same offer suite for years without examining whether it still matches client demand, market position, or the owner's capacity tolerance. This runner gives you the read before you lose a proposal on stale pricing or discover your offer structure is wrong only when you're overextended.

Do not skip steps. Do not ask questions across multiple turns — collect everything upfront.


What you'll have when this is done: A documented evaluation of each offer's performance this quarter, a pricing review with specific adjustments identified, and updated offer documentation reflecting any structural or pricing changes — ready for the next proposal and the next Capacity Planning Review.

Step 1: Collect All Inputs

Ask the user for the following (all at once, in a single prompt):

QBR Results — for each current offer:

Current Offer Documentation — for each active offer:

Quarter Context:

Ideal Client Profile:

Practice Parameters:

Market Context:

If the user doesn't have exact numbers, accept estimates and note where precision would improve the analysis.


Step 2: Review QBR Results by Offer Type

For each offer, build a performance baseline:

OfferRevenueEngagementsClose RateScope vs. SOWTime vs. Price
[Offer][\$X][n][X]%[On track / Over / Under][On track / Over by X%]

Write 2-3 sentences interpreting the table. Flag:

This baseline feeds both the pricing analysis (Step 3) and the offer redesign (Step 4).


Step 3: Pricing Review (Pricing Review Analyzer — Condensed)

Using the QBR data, pricing inputs, and market context from Step 1, produce the following sections.

3A. Current Pricing Snapshot

ServiceCurrent FeeAvg DurationEffective Rate/HourClient Outcome
[Service][\$X][Duration][\$X][What client gets]

The effective hourly rate is the reality check. Calculate it from actual hours worked (from QBR), not SOW hours. Many consultants discover their retainer clients pay \$75/hour effective while project clients pay \$250/hour effective. This table makes the disparity visible.

3B. Value Gap Analysis

For each service, compare:

A healthy consulting engagement delivers 3-10x the fee in value. Above 10x = significantly underpriced. Below 3x = possibly overpriced or under-delivering.

Write one paragraph per service. Name the specific outcomes and estimate the value range. Be honest about what you can and can't quantify.

3C. Market Position Check

Based on the market context inputs, assess:

Key signal: If you're winning every deal, you're underpriced. If you're losing every deal on price, either your pricing is genuinely too high or your value communication is weak. Differentiate between a pricing problem and a positioning problem.

3D. Engagement Economics

Calculate and present:

Red flags: Utilization below 60%. Revenue concentration above 40% in one client. LTV declining year over year. Flag any that apply.

3E. Pricing Recommendations

Limit to 3-5 recommendations. Prioritize by revenue impact. Include at least one "hold the line" recommendation where current pricing is correct.

For each recommendation:

3F. Implementation Sequence

Order the recommendations by:

  1. Immediate (new clients): Changes to apply to new proposals now
  2. Next renewal cycle: Changes to roll into existing client renewals
  3. 90-day preparation: Changes that require groundwork first

Rule: Never recommend changing fees for existing clients mid-engagement without explicit renewal or change order language.


Step 4: Offer Suite Design (Offer Suite Designer — Condensed)

Using the current offer map, pricing analysis output from Step 3, updated ICP, and next-quarter revenue target, produce the following sections.

4A. Current Offer Audit

Map every current service into a diagnostic table:

ServiceDeliverablePriceDurationFrequency/QtrLeads To
[Service][What client gets][\$X][Duration][Count][Next offer or nothing]

Analyze for:

Write a diagnostic paragraph naming the top 3 issues.

4B. Client Journey Map

From the entry and exit data, map the actual client journey:

Identify:

4C. Proposed Suite Architecture

Design a 3-4 tier offer suite (never more than 4):

Tier 1: Entry Offer

Tier 2: Core Offer

Tier 3: Ongoing Offer

Tier 0 (Optional): Free Entry

For each proposed tier, specify: offer name, deliverable, price, duration, and the exact bridge to the next tier.

4D. Pricing Architecture

TierOfferPriceRatioValue Anchor
1[Name][\$X]Baseline[What justifies the price]
2[Name][\$X][X]x Tier 1[What justifies the step-up]
3[Name][\$X/mo][X]x Tier 1/mo[What justifies ongoing]

Step-up logic: Each tier should be 3-5x the previous tier. Smaller gaps don't create enough differentiation. Larger gaps create sticker shock.

4E. Leave Alone / Watch For


Step 5: Evaluate Recommendations Against Capacity

This is the step most people skip — and the reason they add an offer, then realize they can't deliver it.

For each recommendation from Steps 3 and 4:

Filter rule: An offer that requires more delivery hours than you have available is not a growth lever — it's a liability. If any recommendation pushes projected utilization above 75%, it cannot proceed without identifying what stops or shrinks to make room.

For each recommendation, assign one status:


Step 6: Final Decisions and Documentation Updates

For each offer, record the decision:

OfferDecisionEffective DateNotes
[Offer][No change / Price adjust / Scope tighten / Retire / Add new][Date][Key rationale]

If a price increase applies to any offer, flag the Fee Review and Adjustment SOP for execution before the next proposal goes out.


Step 7: Assemble the Offer Suite Evaluation

Present one unified document containing:

# Offer Suite Evaluation: [Practice Name]
## Q[X] [Year]

### Performance Baseline
[Table and narrative from Step 2]

### Pricing Review
[Pricing snapshot from Step 3A]
[Value gap analysis from Step 3B]
[Market position check from Step 3C]
[Engagement economics from Step 3D]
[Pricing recommendations from Step 3E]
[Implementation sequence from Step 3F]

### Offer Suite Analysis
[Current offer audit from Step 4A]
[Client journey map from Step 4B]
[Proposed suite architecture from Step 4C]
[Pricing architecture from Step 4D]
[Leave alone / watch for from Step 4E]

### Capacity Filter
[Evaluation from Step 5 — proceed/defer status for each recommendation]

### Decisions
[Decision table from Step 6]

### Updated Offer Documentation
[For each offer with changes: updated name, deliverable, price, duration, bridge]

### SOPs to Trigger
- [ ] Fee Review and Adjustment — [if any price increases decided]
- [ ] Capacity Planning Review — [if offer changes affect projected utilization]
- [ ] Ideal Client Profile Review — [if offer changes shift target buyer]

Quality Check

Before presenting the output, verify:

CheckPass?
Every current offer from the input appears in the performance baseline
Effective hourly rate calculated from actual hours, not SOW hours
Value gap analysis covers all services, not just the most profitable
At least one "hold the line" pricing recommendation included
Every pricing recommendation has Signal + Do This + Expected Impact + Risk
Offer audit identifies overlap, orphans, gaps, and pricing conflicts
Proposed suite has clear bridges between every tier
Pricing step-up creates appropriate differentiation (3-5x between tiers)
Entry-to-core bridge naturally reveals the need, not just upsells
Every recommendation filtered against capacity — no additions without capacity math
No new offer recommended above 75% utilization without stating what stops
Revenue numbers use exact inputs, not rounded estimates
Dollar signs escaped as \$ for Notion compatibility
Decisions table includes effective dates

Identify the weakest section. Rewrite it. Verify the rewrite before presenting.


Rules

From the SOP:

  1. Never review offers in isolation from capacity. Adding a new offer when you're already at utilization ceiling doesn't expand revenue — it breaks delivery. Offer decisions and capacity decisions are the same decision.
  2. Never delay price adjustments because they feel awkward. If your realization rate is consistently below target, the price is wrong — not your delivery. Every quarter you delay a warranted increase is a quarter of underpriced work.

From the Pricing Review Analyzer:

  1. Never recommend across-the-board percentage increases without specific justification per service.
  2. Always calculate effective hourly rate from actual hours — it's the most revealing metric.
  3. Include at least one "hold the line" recommendation where current pricing is correct.
  4. Don't recommend price decreases unless the data clearly shows overpricing relative to outcomes.
  5. Flag revenue concentration risk if any single client is above 30% of total revenue.
  6. Every recommendation gets a Signal + Do This + Expected Impact + Risk structure.
  7. Never promise specific revenue outcomes — frame as directional expectations.
  8. Never recommend changing fees for existing clients mid-engagement without explicit renewal or change order language.

From the Offer Suite Designer:

  1. Never design more than 4 tiers. Complexity kills conversion.
  2. Always include a bridge between tiers. An offer without a next step is a dead end.
  3. Price based on outcome value, not hours. A 2-hour diagnostic that identifies a revenue leak is worth more than a 20-hour project that organizes files.
  4. Don't kill working offers to achieve theoretical elegance. If it generates good revenue, formalize it into the suite.
  5. The entry offer must be easy to say yes to. If it requires a proposal, a contract, and a 30-minute sales call, it's not an entry offer.
  6. Every offer needs a name. "I could do a strategy session" is not an offer.
  7. Never let the highest tier be open-ended without a review cadence.
  8. If the entry-to-core close rate is below 30%, the entry offer is giving away too much standalone value.

Output format:

  1. Escape dollar signs as \$ for Notion compatibility.
  2. Present as a single unified document, not separate skill outputs.
  3. Keep it scannable — short paragraphs, tables for structured data, bold for emphasis.
  4. If data is incomplete, work with what's available and note assumptions. Never fabricate data.

Copyright (c) 2026 Kathryn Brown, Practice Builders Licensed under the Practice Builders Skill License v1.0 See https://practicebuilders.ai/license for terms.

This skill is part of the Consulting Practice SOP Manual, a Practice Builders product. Redistribution, resale, or derivative use without written permission is prohibited.