---
name: sales-cost-table
description: Generate ForgeFX standard proposal cost tables. Use when creating scope/cost breakdowns, pricing tables, or budget estimates for proposals.
---
Sales Cost Table Skill
Generates ForgeFX-standard cost tables for proposals. Based on the ProposalBot reference design (the gold standard).
When to Use
- Creating a new proposal cost table
- Estimating project pricing for a client
- Generating strawman budgets for internal review
- Any mention of "cost table", "pricing table", "scope and cost", "budget breakdown"
Standard Format
Based on the canonical SharePoint template: `/TeamSite/Internal/Proposals/_Templates/ForgeFX-Cost-Table-Template.xlsx`
Columns (6 tiered options)
| # | Column | Description |
|---|--------|-------------|
| 1 | **#** | Sequential item number (1, 2, 3) |
| 2 | **Title** | Short feature/deliverable name |
| 3 | **Description** | Brief scope description. 1-2 sentences. |
| 4 | **Option A** | Core / minimum viable scope. Dollar amount. |
| 5 | **Option B** | Standard scope. Dollar amount. |
| 6 | **Option C** | Full scope. Dollar amount. |
Tiering Logic: Goldilocks Model
**CRITICAL: Option A (baby bear) MUST total less than $100,000.** This is a hard ceiling.
Options are **additive by feature**, not by price tier within each feature. Each feature is either IN or OUT of a given option. The typical pattern for 10 features:
- **Option A** Features 1 through ~4. Core minimum. Always < $100K total.
- **Option B** Features 1 through ~7. Standard scope. Includes everything in A plus mid-tier features.
- **Option C** Features 1 through 10. Full scope. Every feature included.
In the spreadsheet, features excluded from a tier show **$0**. Features included show their full price (same price across all tiers that include them).
Self-Contained Features
**Each feature must be a self-contained deliverable**, not a process step. A feature includes its own discovery, development, testing, QA, and deployment as needed. Do NOT create separate line items for cross-cutting concerns like "Testing and QA" or "Deployment" -- bake those into each feature price.
This ensures Option A is a shippable product with just features 1-4, Option B is shippable with 1-7, etc. No feature depends on a later line item to be complete.
**Wrong:** Feature 1 = Physics, Feature 2 = Environment, ... Feature 10 = Testing and Deployment
**Right:** Feature 1 = "Robot Physics and Controls" (includes its own testing), Feature 2 = "Urban Environment" (includes its own QA), etc.
Feature Ordering
Order features from most essential to least essential. The first ~4 features should form a coherent, usable minimum product. Features 5-7 expand it meaningfully. Features 8-10 are nice-to-haves or advanced capabilities.
Visual Design
Reference styling: `examples/cost-table-reference-styling.png` (the approved gold standard — match it).
- **Header row:** Gold (#F6B104)
- **Data rows:** Cream (#FDF2E7)
- **Totals row:** Dark slate (#5C708A), uses SUBTOTAL(109,...) formula
- **Font:** Calibri throughout
- **Currency format:** $#,##0 (whole dollars, no cents)
- **Title column: BOLD.** Titles are bold to anchor each row and reduce reader cognitive load.
- **Alignment (every cell vertically centered — no exceptions):**
- # column: horizontal center, vertical center
- Title column: horizontal left + indent 1, vertical center, **bold**, wrap text on
- Description column: horizontal left + indent 1, vertical center, wrap text on
- Option A/B/C columns: horizontal right + indent 1, vertical center (dollar values); excluded cells show a centered em-dash (—) in a muted gray, horizontal + vertical center
- **Word wrap + row height:** Title and Description columns must wrap. Set explicit row heights (~15.5px per wrapped line) so full descriptions render in file-preview screenshots, not just when a cell is clicked.
- **Page setup:** Landscape, fit-to-width = 1 page, so previews show every column instead of clipping the Option columns onto a second page.
- **Excel Table:** Table1, TableStyleMedium14, row stripes off, filter buttons disabled
Hourly Math
The template shows **flat dollar amounts only**. Hourly calculation ($185/hr x hours) is done externally. This keeps the deliverable clean and scope-focused.
Pricing Guidelines
| Project Type | Typical Range | Typical Phases |
|-------------|---------------|----------------|
| POC / Pilot | $75K-$150K | 3-4 phases |
| Standard Project | $150K-$400K | 4-6 phases |
| Enterprise / Multi-phase | $400K-$1M+ | 5-8 phases |
| VR Training (full) | $200K-$500K | 5-7 phases |
| WebGL/Browser Sim | $100K-$250K | 4-5 phases |
Rate Card Reference
| Role | Proposal Rate |
|------|--------------|
| Blended (default) | $185/hr |
| Senior Engineer | $225/hr |
| 3D Artist | $175/hr |
| Project Management | $185/hr |
| QA/Testing | $150/hr |
Most proposals use blended $185/hr for simplicity.
Usage
1. Gather scope from: meeting transcripts, Fireflies, Jira, Salesforce, Slack channel
2. Break scope into ~10 **self-contained** features, ordered most-to-least essential
3. Estimate dollar amounts per feature ($185/hr x hours externally, bake testing into each feature)
4. Assign features to tiers: first ~4 = Option A (must be < $100K), first ~7 = Option B, all 10 = Option C
5. Verify Option A < $100K. If not, rebalance.
6. Generate table in markdown for review
7. Once approved, generate .xlsx
For raw BOE/WBS spreadsheets that need to be compressed into the standard 10-row shape, use `references/boe-to-10-row-cost-table.md`. The key move is to group internal work packages into buyer-visible deliverables, keep Option A as a paid definition/prototype package under $100K, and surface support/data/hardware assumptions as visible pricing risks.
When Adam asks to soften, decrease, reduce, dial back, harden, increase, or tighten cost-table scope commitments by a percentage, use `references/commitment-softening-playbook.md`. The descriptions are the commitment surface: rewrite every line-item description so the client-facing promise matches the requested percentage change before treating reduced hours/pricing as safer.
Notes
- Always label as "STRAWMAN" or "DRAFT" until approved by Adam/Greg
- Round hours to nearest 10 or 20 for cleanliness
- Include a 10-15% contingency buffer baked into phase estimates
- For enterprise clients ($1B+ revenue), price confidently. Do not undercut.
- The $185/hr blended rate is non-negotiable. Discounts require Adam approval.
Field Notes (learnings, not mandates)
Captured feedback from real proposal runs. Apply with judgment.
Devin, 2026-06-09 (TMEIC) — cheatsheet, $100 placeholder, wrap-everything
- **Single page, 3 options is the ideal shape.** A cost sheet should aim to be one page the client can pick from, with three clear options. When you've produced several framings of the same proposal (e.g. a small comms-PoC sheet, a full-phase sheet, and a combined ladder), add a **cheatsheet page** that compares them and marks the recommended one. Cheatsheet layout that worked: one row per sheet; columns `Cost Sheet | What It Covers | Option A | Option B | Option C | Pick`; Option cells hold a short tier label + total (e.g. "A - Comms PoC / $90,000"); the recommended row gets a gold-tint fill (`#FCE2B0`) + bold name + "★ RECOMMENDED" in the Pick column; a short italic recommendation rationale + pricing-note row sit below the table. Recommend the framing that best delivers "one page, three commitment levels."
- **Uncertain pricing → use $100 per line item as a deliberate placeholder** so it visibly stands out as "not yet estimated," rather than guessing. Call the convention out (a note on the sheet: "$100 = placeholder for scope not yet estimated, not a real price"). Do not silently invent a number when scope is unknown.
- **Enable word wrap on ALL cells by default**, not just Title/Description — description text was clipping. Set `wrap_text=True` on every cell and give rows generous explicit heights so nothing is cut off in the file-preview screenshot.
SharePoint Read-Only Viewer Links
When uploading cost table files to SharePoint, always provide a read-only viewer link:
`action=view` opens in browser with no lock. Always prefer this.
Commitment softening / hardening playbook
Use this when Adam asks to "soften," "decrease," "reduce," "dial back," or "lower" cost-table scope commitments by a stated percentage across the board. Also applies in reverse when he asks to "harden," "increase," "tighten," or "raise" commitments.
Core idea
In a ForgeFX cost table, the **description text is the commitment surface**. The hours and price feel safer only when the written scope promises less. Do not merely cut numbers. Rewrite every line item so the client-facing commitment matches the intended reduction in obligation.
Softening by X% means: reduce the strength, breadth, specificity, certainty, and completion promise of each line-item description by roughly X%, while keeping the line item useful and honest.
Hardening by X% means: make the line-item descriptions more complete, explicit, guaranteed, integrated, or acceptance-ready, and expect pricing/hours to rise accordingly.
Trigger phrases
Treat these as the same workflow:
- "soften the commitments by 25%"
- "soften the cost table line item scope commitments by 50%"
- "decrease commitments across the cost table"
- "reduce scope promises by 10%"
- "make the line items less committed"
- "dial back the descriptions"
- "harden commitments" / "increase commitments" / "tighten commitments" when the direction is upward
Softening levels
10% soften — light hedge
Use when the price is close but the wording is a little too strong.
- Keep the same deliverable.
- Replace absolute language with bounded language.
- Add client-input dependencies.
- Clarify that final details are subject to scope lock.
Example moves:
- "Develop the full-function operator cab simulator" → "Develop a production-oriented operator cab simulator based on agreed control/display requirements."
- "Complete data ownership/export features" → "Provide agreed data/export features for the prioritized reporting workflow."
25% soften — narrower acceptance
Use when hours need a meaningful reduction but the option should still feel credible.
- Reduce breadth of included variants, scenarios, reports, integrations, or environmental detail.
- Move some depth into assumptions or later change-order language.
- Convert "all / full / complete" to "priority / representative / agreed / initial."
- State that content depth depends on source-data quality and review availability.
Example moves:
- "Model the existing Blue Line and Green Line alignments, stations, yards, signals, switches, crossings, overhead catenary, signage, and training-critical infrastructure" → "Model prioritized Blue/Green Line segments and training-critical infrastructure needed for the agreed scenarios, based on available source data."
50% soften — controlled starter scope
Use when the current row reads like a full build but pricing needs to behave like a starter package.
- Convert full production promises into prototype, representative, baseline, or first-pass scope.
- Remove implied exhaustive coverage.
- Limit deliverables to a defined subset, one workflow, one route segment, one reporting package, or one demonstrator.
- Push advanced support, integrations, content variants, and long-tail polish into later options/change orders.
Example moves:
- "Full-function operator cab simulator with physical controls, displays, instrumentation, audio, calibration, and commissioning support" → "Representative cab-simulator package covering the agreed core operator workflow, with physical-control/display assumptions documented for later production expansion."
Hardening levels
When Adam asks to harden/increase commitments, reverse the softening logic:
- Replace "representative" with "production-ready" only when pricing supports it.
- Replace "prioritized" with named coverage.
- Add acceptance criteria, commissioning, documentation, support, and integration depth.
- Name included variants, reports, environments, devices, or workflows.
- Increase price/hours or flag that the existing number no longer supports the wording.
Batch process
1. Identify the requested direction and percentage.
2. Preserve the 10-row structure and option inclusion pattern unless Adam asks to change rows.
3. Rewrite every line-item description at the requested commitment level.
4. Keep titles mostly stable unless a title itself overcommits.
5. Adjust pricing only if requested; otherwise mark the table as a wording/commitment pass and flag pricing for review.
6. Add a note to the table: `Commitment wording softened by <X>% for pricing comfort; final scope requires SME approval.`
7. Verify Option A still stays under $100K and the option totals still match the intended pricing model.
Do not
- Do not cut prices while leaving full-scope descriptions intact.
- Do not hide exclusions in vague language; state boundaries plainly.
- Do not soften safety, compliance, legal, or warranty obligations into misleading promises.
- Do not change the commercial meaning of a row without leaving a visible note for review.
Output expectation
When asked to soften/harden commitments, return:
1. A revised cost table with updated descriptions.
2. A short change note explaining the requested percentage and direction.
3. A risk note naming which commitments were moved into assumptions, later options, or change-order territory.
4. If generating `.xlsx`, include the softening/hardening note in a `Meeting Notes` or `Assumptions` sheet.