rba-rfp-prep-proposal

Standalone Web-only skill. Copy it into Claude, or drop it into your project.

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

RBA RFP Prep / Pre-Envision Proposal

Purpose

Draft a complete, defensible RBA Consulting proposal for a CMS/DXP platform selection RFP preparation engagement. The output is a markdown document the team can iterate on with the client and later move into deck or Word format. The skill produces draft 1; iteration with the team happens through normal conversation afterward.

When to apply

Any request to draft, scope, or estimate an RFP prep / pre-envision engagement
Conversations that include a client name, current CMS/DXP details, and a target RFP issuance window
Requests that mention "platform selection," "CMS evaluation," "DXP RFP," "vendor selection," or "envision phase" for the platform-selection portion
Internal RBA conversations among Tyler, Brett, Rachelle, Eric, or other team members about proposal drafting for this engagement type

When to skip

Requests for build, implementation, or post-RFP delivery proposals (different methodology, different pricing anchors)
Brand strategy, content strategy, or pure UX engagements without a platform RFP component
Internal RBA documents that are not proposals (status reports, retrospectives, etc.)
Audit or rewrite requests for existing content (route to rba-brand-voice if voice-only)

Workflow — draft mode

This skill runs 13 steps. Steps 1–5 are intake and alignment; steps 6–9 are analysis; step 10 is drafting; steps 11–12 are user-facing verification checkpoints; step 13 is the brand voice pass.

Step 1 — Capture from conversation

Pull everything possible from conversation history before asking the user anything:

Client name, sector, geography
Current stack (CMS/DXP, MA, CRM, DAM, core systems, locations, CMP)
Target launch date, target development start date
Constraints already stated (SaaS/headless, hosting, dev bench skill set)
Candidate platforms the client has named
Existing artifacts the client has produced (user stories, requirements drafts, shortlists)
Any RBA people named as engagement team
Brett's likely budget signal if mentioned
Any blended rate, role rate card, or pricing context already given

Extract these into a working intake summary. Do not move to step 2 until this is complete.

Step 2 — Systems verification with user

Before any further intake, present the systems landscape to the user for explicit confirmation:

Current systems — what is in place today
Systems being replaced — CMS/DXP is always primary; surface anything else the engagement may replace
Systems being added — CMP, DAM, search, locations data system, etc.
Systems being removed — what goes away
Systems staying as-is — what is not touched

Ask explicitly: "Does this systems landscape match what you understand for [client]? Anything to add, remove, or correct?"

This step protects against drafting around the wrong stack. Do not skip it even when conversation history seems complete.

Step 3 — Run structured intake on gaps

For fields still missing after steps 1–2, use ask_user_input_v0 with discrete tappable options. Group questions in sets of three or fewer. The gating questions in order of importance:

How transformative is this expected to be? Like-for-like swap / focused replacement / member experience reimagining. This drives tier selection.
Hard constraints — SaaS allowed? Headless allowed? Hosting requirement?
Decisioning architecture — does the marketing automation platform own decisioning, or does the CMS? Wings is "Blueshift decides, CMS renders" — explicit in their docs. Surface this for the client.
Open architecture or system-of-record decisions — ask: "What decisions about where data lives, who authors content, or what platform owns a function are still open?" Listed examples include locations (Yext vs. CMS), authoring (in-house vs. partner), search (native vs. third-party). The question is broader than the examples — provider directories, dealer locators, course catalogs, event calendars, member portals, and similar domain-specific patterns all qualify. These often become conditional uplifts (see references/conditional-uplifts.md, Pass B).
Branding / M&A context — any post-merger brand architecture work? Multi-brand portfolio? This affects multi-site requirements depth.
Budget signal — is there a budget target the proposal needs to hit?
CRM direction — known or TBD? Unknown CRM is usually the biggest requirements-matrix gap.
Product Owner access — single owner with decision authority + access to teams within two business days?

Skip questions where conversation already provides the answer. The intake is permission to ask, not an obligation.

Step 4 — Rate verification with user

Before pulling pricing anchors or drafting any estimate, confirm the blended rate or role rate card with the user. The standard is $165/hr blended — RBA's current internal resource-plan rate. Confirm explicitly even when the standard applies:

"Confirm the engagement runs at the $165/hr blended rate, or provide a different blended rate or role-based rate card."

If any rate assumption gets made later in drafting — for example, add-on pricing or a role mix that varies from standard — surface the assumption explicitly and ask the user to confirm before proceeding. Never bake an unconfirmed rate into the estimate.

Step 5 — Understanding check #1 (pre-analysis alignment)

Before moving to analysis and drafting, summarize the engagement understanding back to the user and surface every assumption. Include:

Client name, sector, key business context
Scope: what is in, what is out
Tier signal so far (transformative answer + budget signal)
Hard constraints and their implications
Open architecture decisions surfaced (candidate uplift triggers)
Identified conditional uplifts (Pass A candidates so far, Pass B candidates to investigate)
Confirmed rate or rate card from Step 4
Key assumptions you are making

Ask explicitly: "Does this match your understanding of [client]? Anything to correct before I move into analysis and drafting?"

Do not proceed to step 6 without explicit user confirmation.

Step 6 — Identify conditional uplifts (two passes)

Pass A — known patterns. Walk references/conditional-uplifts.md. For each pattern in that file, decide whether it applies, partially applies, or does not apply.

Pass B — generate new candidates from intake. Scan the intake for every open question, TBD item, and unresolved architecture decision that Pass A did not cover. For each one, apply the three uplift criteria in references/conditional-uplifts.md:

Is the answer genuinely unknown at intake?
Does one answer significantly expand Phase 3, Phase 4, or both?
Does the RFP need the right answer to ask vendors the right questions?

If all three pass, the item is a new uplift. Name it, size it using the scaling pattern in references/conditional-uplifts.md, and add it as a new line item in the estimate table.

The reference file lists common patterns observed across past RBA engagements. It is not a closed set. Every client surfaces something new — provider directories in healthcare, dealer locators in manufacturing, course catalogs in education, member portals in associations. Treat the file as a starting library, not a checklist.

Conditional uplifts go in Phase 3 expansion, Phase 4 expansion, or as a base-plus-uplift line in the estimate table. Multiple uplifts stack as separate rows.

Step 7 — Pick a default tier

Use the answer to the transformative-scope question and the budget signal:

Client signal	Default tier
Like-for-like, fast, sub-$100K budget signal	Focused
Matches the brief described, moderate budget	Recommended
"Yes, transformative" + active brand or member experience work	Transformative-Ready
Ambiguous on transformative + no budget signal	Recommended with 30-day checkpoint to re-tier

See references/tier-structure.md for the full model.

Step 8 — Pull pricing anchors

MANDATORY human-in-the-loop money gate. Before finalizing or outputting any fees, prices, payment terms, rates, or total dollar figures, you MUST present the proposed monetary figures to the user and STOP to require their explicit validation and approval. Do not silently produce final monetary commitments. Present the figures and the assumptions behind them, ask the user to confirm or correct them, and wait for explicit approval before producing the final output. If the user has not approved, do not finalize or write the money figures. (Step 11 — Math verification — is the concrete enforcement of this gate; it is non-negotiable.)

Load references/pricing-anchors.md. Compare the engagement to the closest precedent. Anchor the Recommended tier total to that precedent ± 25% based on scope variance. Derive Focused and Transformative-Ready from there.

The blended rate confirmed in Step 4 drives all dollar calculations. Hours flex during alignment by 5–10% if Tyler signals.

Step 9 — Pick case studies

Load references/case-study-bank.md. Pick six case studies for the mini-card format Tyler prefers:

At least one sector match (banking, credit union, healthcare, member org, etc.)
At least one platform match (Optimizely, Sitecore, Kentico, Sitefinity, Umbraco, etc.)
At least one engagement-type match (platform evaluation, re-platform, Pre-Envision + Envision)
At least one Harvey-ball scorecard methodology demonstration (Donaldson, Barnes & Thornburg, MidWestOne Bank)

If the client is in financial services, surface the banking implementation case studies (Banner, BCU) as a separate callout — "different positioning" — for implementation-capability questions only.

Step 10 — Draft sections in order

Use references/proposal-template.md as the structural skeleton. Fill section by section in this order:

Header (client name, prepared for, prepared by, engagement, version)
- Include the internal-only banner immediately after the header block. See proposal-template.md for the standard banner text. This banner is mandatory on every draft.
TL;DR (outcome-leading bullets, four to six items)
Key Findings (numbered, each leads with a bold finding statement)
Why RBA + case studies (the unbiased-positioning section)
Our Understanding of [Client]'s Situation (stack table, what they've done, hard constraints + open questions)
Recommended Approach (Phase 0–5, each leading with "What [Client] gets")
Initial Estimate (tier comparison table with base and with-uplift rows, tier descriptions, role allocation for Recommended, optional add-ons, assumptions)
Timeline (working backward from the development start date)
Assumptions, risks, and dependencies (load references/risk-patterns.md)
Recommendations and next steps (one primary CTA — the executive walkthrough)
Caveats

Outcome-leading framing matters at every level. Lead the TL;DR with what the client gets. Lead each phase with "What [Client] gets:". Lead each tier with what's delivered before the dollars.

Step 11 — Math verification with user (REQUIRED — no exceptions)

Before any final output is produced, present the math to the user for explicit verification. This is a hard rule with no exceptions. Show the calculations clearly enough for the user to spot errors:

Tier base totals. For each tier, show the phase-by-phase hour sum and the dollar total at the confirmed blended rate:

Focused base: P0 32 + P1 160 + P2 100 + P3 60 + P4 80 + P5 108 = 540 hrs × $165 = $89,100 Recommended base: P0 48 + P1 240 + P2 160 + P3 130 + P4 140 + P5 122 = 840 hrs × $165 = $138,600 Transformative-Ready base: P0 56 + P1 290 + P2 180 + P3 160 + P4 160 + P5 144 + Journey 60 = 1,050 hrs × $165 = $173,250

Conditional uplifts (per tier). For each uplift, show per-tier hours and dollars and the comparable it was scaled from.

With-uplift totals. For each tier, show base + sum of uplifts = with-uplift total.

Optional add-ons (if included). Show each add-on's math.

Ask explicitly: "Verify the math before I finalize. Confirm or call out any error."

Do not proceed to Step 12 (or any final output) without explicit user confirmation. This is the hardest of the hard rules.

Step 12 — Understanding check #2 (pre-output alignment)

After math verification confirms, summarize the drafted proposal's approach and surface every baked-in assumption before the brand voice pass:

Tier recommendation and rationale
Conditional uplifts identified and how each is sized
Key risks surfaced
Open questions remaining for the client
Any tradeoffs or compromises in the draft
Key assumptions baked into the draft

Ask: "Final read before brand voice pass — anything to adjust?"

Do not proceed to Step 13 without explicit user confirmation.

Step 13 — Apply the rba-brand-voice skill

Pass the complete draft through the rba-brand-voice skill in audit mode. Apply every finding it returns. Do not skip this step — the proposal voice and the brand voice need to match before returning to the user.

When returning the final output, restate that the markdown is an internal RBA working document and not for direct client distribution. The team converts to a proposal PDF, deck, or Word document before sharing with the client.

Key brand voice traps for this engagement type:

"Stakeholder" — replace with "team," "leader," or "client" depending on context
"Leverage" — replace with "use," "apply," or "build on" (or "negotiating position" / "pricing power" when describing client-side benefits)
Passive voice in the assumptions, risks, and caveats sections — these tend to passive by default
Em dash spacing — never spaces around em dashes
Contractions in proposals — expand them all
Single-digit numbers in prose ranges — spell out endpoints
Compliance language — probabilistic phrasing only

Intake checklist

Before drafting, confirm these fields:

Client name, sector, geography, asset/revenue size
Current CMS/DXP + version
Current marketing automation / decisioning platform
Current CRM (or "TBD")
Current DAM (or "TBD" / "None")
Current locations data system (Yext, native, none)
Current CMP (or "None")
Core system the CMS integrates with (banking, EHR, ERP, etc.)
Systems landscape confirmed with user (current / replaced / added / removed / staying)
Target launch date + target development start date
Hard constraints: SaaS, headless, hosting, dev bench skill set
Candidate platforms named by the client
Existing client artifacts (user stories, requirements drafts, shortlists)
Transformative scope answer
Budget signal
Blended rate or role rate card confirmed with user
Branding/M&A context
Open architecture or system-of-record decisions (from any domain)
Identified conditional uplifts (Pass A) and candidate uplifts (Pass B)
Understanding check #1 confirmed by user (pre-analysis alignment)

If any of these fields are unanswered after conversation + intake, flag them explicitly in the proposal's Open Questions section rather than guessing.

Reference pointer table

When you need...	Read...
Phase structure, deliverables per phase, hours per tier per phase	references/methodology.md
Three-tier model, how to pick a tier, threshold conditions	references/tier-structure.md
Historical RBA engagement precedents and the $165/hr blended rate	references/pricing-anchors.md
Common conditional uplifts (locations, multi-brand, multilingual, AI compliance, data maturity) and how to spot new ones	references/conditional-uplifts.md
RBA case studies tagged by platform, sector, and engagement type	references/case-study-bank.md
Standard risks for this engagement type with mitigations	references/risk-patterns.md
Section-by-section markdown skeleton with placeholders	references/proposal-template.md

Composition with rba-brand-voice

Step 13 of the workflow applies the rba-brand-voice skill in audit mode. This is non-optional. The brand voice skill catches:

Banned vocabulary (world-class, cutting-edge, synergy, leverage, robust, seamless, empower, holistic, operationalize, stakeholders, solution)
Em dash and en dash spacing
Passive voice density
Contractions in formal context
Single-digit numbers in prose
Compliance-language absolutes
Inclusive-language replacements (execute, blind spot, ballpark, kill-switch, etc.)
Missing approved brand phrases (Powered by People. Enhanced by AI. / Designed to Deliver. / trusted talent, proven technology, applied AI to deliver measurable results / meet you where you are / from idea to execution, with clarity, speed, and confidence)

After applying the rba-brand-voice findings, the proposal is ready to share.

Hard rules

Always present three tiers (Focused / Recommended / Transformative-Ready). Even when one tier is clearly correct, the other two give the client decision authority and protect against scope drift.
Always anchor pricing to a named RBA precedent in references/pricing-anchors.md. No invented benchmarks.
Always run Step 2 (Systems verification) and Step 4 (Rate verification) before any analysis or drafting begins. These are user-facing confirmations, not internal checks.
Always confirm Understanding Check #1 (Step 5) before moving from intake into analysis.
Always run Step 11 (Math verification) before producing any final output. NO EXCEPTIONS. The user must explicitly verify the math before the brand voice pass.
Always confirm Understanding Check #2 (Step 12) before the brand voice pass.
Always run Step 13 (rba-brand-voice pass) before returning the draft. Never skip it.
Always include the "Why RBA — unbiased, platform-agnostic selection" section. The unbiased positioning is core to this engagement type — clients consistently surface concern that RBA will push a preferred platform.
Never bake an unconfirmed rate into the estimate. If any rate assumption gets made beyond Step 4 (e.g., for add-ons or specialized roles), surface it explicitly and confirm before proceeding.
Never include full content strategy and design as base scope. That work is a separate six-figure engagement. Phase 3 is advisory only.
Never include the actual RFP authoring as the deliverable. The deliverable is a requirements package + recommended RFP structure; the client formats and issues the RFP themselves.
Never claim guaranteed compliance outcomes. AI governance, accessibility, and data privacy language stays probabilistic, with the approved closing qualifier from rba-brand-voice.
Never share the raw markdown output with the client. The skill produces a working document for internal RBA review and iteration only. Before any content reaches the client, the team moves it into a client-facing format — proposal PDF, PowerPoint deck, Word document, or similar. The internal-only banner at the top of every draft is mandatory; it documents this rule inside the file itself.

Self-check before returning

Ask:

Was Systems verification (Step 2) confirmed by the user?
Was Rate verification (Step 4) confirmed by the user?
Was Understanding check #1 (Step 5) confirmed by the user?
Was Math verification (Step 11) confirmed by the user? This is mandatory — no exceptions.
Was Understanding check #2 (Step 12) confirmed by the user?
Is the internal-only banner present at the top of the proposal (after the header block, before the TL;DR)?
Does the TL;DR lead with what the client gets, or with what RBA does?
Does each engagement phase lead with "What [Client] gets:"?
Does each tier description lead with what is delivered before the dollars?
Are three tiers present and pricing anchored to a named precedent?
Have conditional uplifts been identified, with hours and dollars per tier?
Is the rba-brand-voice audit complete and applied?
Does this read like a confident, human RBA expert who cares about the client's results — not a generic consulting firm?

If any answer is no, revise before returning.

Technical details

Source: Standalone skill
Author: Tyler Schroeder
Skill name: rba-rfp-prep-proposal
Maturity: experimental
Security review: No security review
File: skills/rba-rfp-prep-proposal/SKILL.md

To use this skill in Claude Code, copy SKILL.md into your local .claude/skills/rba-rfp-prep-proposal/ directory. Standalone skills are not exposed via claude plugin install — that path is reserved for plugin bundles.

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.