Brainforge Knowledge

offer-template

3 min read

Offer: [Service Name]

About this document (Brainforge)

Internal conventions for how this file works in the repo. Strip or export without this section when sharing with a client.

Titling and filename

Use Offer: [Service Name] for the document title. Example: Offer: Omni Zero-to-One Analytics.

Filename: knowledge/sales/services/{service-line}/{offer-name}/offer.md.

When to use this template

Use this when defining a new Brainforge service offering for the sales pipeline. This document describes who it’s for, what problems it solves, and how it’s priced. It feeds into campaign briefs, lead plays, and SOWs.

Do not use this template when:

  • drafting a specific client SOW (use the SOW template)
  • writing a campaign brief (use the Campaign Brief template)
  • quoting pricing for a specific deal (use the Pricing Quote template)

Purpose: How we pitch this service to a lead.
Notion: Offers database
One-liner: [One sentence: what we do and the main outcome, e.g. “We help you get 95%+ reporting accuracy before client-side tracking can fail.”]

ArtifactLink / pathNotes
Campaign Brief (if launched)[path]Campaign that markets this offer
SOW templateknowledge/standards/02-writing/SOWs/sow-template.mdSOW for this service
Pricing referenceknowledge/sales/pricing/DYNAMIC_PRICING_GUIDE.mdPricing methodology
Delivery SOP / playbook[path]How this service is delivered

Who it’s for

  • Roles: [e.g. Head of Marketing, CMO, Head of Growth]
  • Industry: [e.g. E‑commerce, CPG, B2B SaaS]
  • Preconditions: [What must be true for this offer to fit — budget, tools, team, problem already felt]

Business problems (in buyer words)

  • [Problem 1]
  • [Problem 2]
  • [Problem 3]

Outcomes (30–90 days)

  • Time saved: [What gets faster + how we’d measure]
  • Revenue / profit: [Attribution, waste reduction, etc.]
  • Efficiency / clarity: [Fewer debates, single source of truth, etc.]

What we do (scope at a glance)

  • [Capability 1] — [One-line outcome]
  • [Capability 2] — [One-line outcome]
  • [Capability 3] — [One-line outcome]

Optional add-ons: [e.g. Compliance/PII, Bot filtering] — [when to offer]

Proof

  • Case snippet: [2–3 lines, anonymized if needed]
  • Metrics: [e.g. “Recovered ~17% of customers with no prior attribution visibility”]
  • References: [Available upon request / link to case study]

Pricing (anchor)

  • Model: [Fixed / milestone / retainer / audit → pilot → scale]
  • Range: [e.g. Audit Y–$Z | Scale by scope]
  • Link to rate card: [gtm/pricing/RATE_CARD.md] (or specific section)
  • SOP (delivery playbook): [Notion link or path to SOP doc]
  • Demo(s): [Notion links or paths to demo docs]
  • Sales assets: [e.g. gtm/agents/service-assets/xxx-deck.md, one-pager, landing]

Appendix A — Agent guardrails (anti-fluff)

Do:

  • Write problems in the buyer’s language, not Brainforge terminology.
  • Lead with outcomes, not features.
  • Price ranges should include a clear anchor (what the client should expect to pay).
  • Differentiate this offer from adjacent offers explicitly.

Do not:

  • Use filler descriptors (“game-changing”, “best-in-class”, “industry-leading”, “revolutionary”).
  • Overclaim outcomes — if metric is estimated, say “estimated.”
  • Write the offer without knowing who it’s for (roles, industry, preconditions must be filled first).
  • Let “Links” section go stale — verify SOP, demo, and asset links before pitching.

Appendix B — Pre-handoff QA checklist

  • Who it’s for is specific (roles + industry + preconditions)
  • Problems are stated in buyer language
  • Outcomes are concrete and time-bound (30–90 days)
  • Pricing has a clear model and range
  • Proof includes a real case snippet or metric (not “case study available”)
  • All links in Links section are verified
  • Offer is differentiated from adjacent offers in the catalog

Graph View