​

Enterprise Pricing Model — Iterations & Thinking

Status: Work in progress. We are still iterating on this model. Last updated: 2026-04-15

​

Context

• The unit is clear (tool calls)
• Every tier has a calculable $/call
• Customers understand what they’re buying
• Upgrades have obvious math (“4x the calls for 2x the price”)

​

Iteration 1: Flat Tiers with Tool Call Caps

​

The idea

​

Why we moved away from this

1. Cost-per-call paradox. Enterprise ($0.067/call) was marginally MORE expensive per call than Max ($0.066/call). Higher volume should mean lower unit cost, not higher.
2. Tool call caps don’t match the “unlimited” promise. We made Max unlimited. Putting a 15,000 cap on Enterprise (which costs 5x more) feels regressive. Customers would ask: “Why am I paying more and getting less?”
3. Overage billing not implemented. The enterprise page promised overage rates ($0.05/call,$0.04/call), but the codebase hard-blocks users at their limit. Selling a feature we can’t deliver.
4. “Why not just buy 7 Max plans?” At $199/mo × 7 =$1,393/mo, a team gets unlimited calls per person. Enterprise at $999/mo with 15,000 shared calls looked like a worse deal.
5. Tool calls cost us almost nothing. The cost to Adspirer per tool call is negligible. Capping them creates friction without reflecting real costs.

​

Iteration 2: Unlimited Tool Calls + Account-Based Differentiation

​

The idea

​

What improved

• Eliminated the “why not buy 7 Max plans” problem — account limits (5 per platform on Max) create a hard gate.
• Tool calls no longer a source of friction.
• Sequential subagents became the enterprise differentiator — running operations across 50 or 200 accounts is qualitatively different from 5.

​

Problems that remained

1. No clear pricing unit. Consumer plans have $/call. Enterprise had… nothing. Just tiers with different feature bundles. How do you negotiate? How do you price a custom deal for someone with 80 accounts?
2. The 2-3x gap between tiers. Enterprise at $12K, Enterprise Plus at$24K-$36K. Customers in between (e.g., 100 accounts, 7 seats) had no good option.
3. Seat vs. account tension. Some customers need many accounts but few seats (solo agency owner with 50 clients). Others need many seats but few accounts (in-house brand with 10 marketers on 5 accounts). A fixed bundle doesn’t fit either well.

​

Iteration 3: Per-Account Pricing (Cost per Account per Month)

​

The idea

​

What improved

• Clear unit economics, mirroring $/call for consumer plans.
• Custom deals calculable with simple math.
• Volume discount story is clean: more accounts = cheaper per account.

​

Why it wasn’t enough

1. Doesn’t account for seats. An in-house brand with 10 people and 5 accounts generates massive compute — 10 people hammering 5 accounts all day. Per-account pricing would put them on Max ($33/account × 5 =$165/mo), which dramatically underprices the actual system load.
2. Ignores the interaction effect. 10 seats × 200 accounts is not 10 + 200 — it’s a multiplicative load. More users on more accounts means cross-account queries, concurrent sequential subagent runs, and exponentially more agent work.
3. No framework for handling seat-heavy customers. “We have 3 people but 200 accounts” prices correctly. “We have 20 people but 5 accounts” doesn’t.

​

Iteration 4: Seats + Accounts (Additive Model)

​

The idea

price = (seats × per_seat_rate) + (accounts × per_account_rate)

• Per seat: $120/mo (Max) →$100/mo (Enterprise) → $80/mo (Enterprise Plus)
• Per account: $16/mo (Max) →$12/mo (Enterprise) → $8/mo (Enterprise Plus)

​

Test scenarios

​

Why it wasn’t enough

​

Iteration 5: Compute Units = Seats × Accounts (Multiplicative Model)

​

The core insight

• Cross-account operations: A user says “pull performance across all 200 accounts.” The agent fans out across all 200 — fetching data, loading context, aggregating results. That’s O(accounts) per request.
• User amplification: 10 users triggering cross-account operations concurrently = 10 × O(accounts) concurrent load.
• Sequential subagents: Running campaigns across 50 accounts means 50 account traversals with context switching. With 5 users doing this simultaneously, that’s 250 concurrent account contexts.
• Read-only users (analysts): Even read-only users generate heavy compute — “compare CTR across all 200 accounts” requires the agent to fetch and reason over 200 datasets.

​

The formula

CU = seats × accounts

​

Effective $/CU at published prices

​

Why does $/CU drop with volume? (Important caveat)

• Larger annual deals = lower customer acquisition cost per dollar of revenue
• Annual lock-in = lower churn
• First enterprise logos = marketing/social proof value
• Competitive pressure = enterprise buyers expect volume discounts

​

Current Thinking: Base + Add-On Model (Built on CU Framework)

​

Published tiers (on the docs page — current)

​

Add-on rates (for custom configurations)

​

Natural upgrade breakpoints

$199 + (X × $8) = $1,000 → X = 100 accounts

Enterprise with 10 seats + 200 accounts:
$1,000 + (5 × $100) + (150 × $5) = $1,000 + $500 + $750 = $2,250/mo
Enterprise Plus: $2,000/mo ← cheaper

​

Custom deal scenarios

Enterprise Plus published: $30,000/yr
CU model: 9 × 200 = 1,800 CU
Katie negotiates 15% off: $25,500/yr
Katie negotiates 20% off: $24,000/yr

Enterprise at $12,000/yr (covers 5 seats + 50 accounts)
They need 10 seats → add 5 seats at add-on rate
Custom price: ~$18,000/yr

Max ($199/mo) + additional accounts at add-on rate
Custom price: $500-$600/mo = ~$6,000-$7,200/yr

CU: 30 × 500 = 15,000 — well beyond Enterprise Plus
Custom deal territory — contact sales

​

Negotiation framework

1. Calculate CU: seats × accounts
2. Compare to published tier that best fits
3. Negotiation room: up to 15-20% off published price
4. For configurations between tiers: use add-on rates from base tier
5. For configurations beyond Enterprise Plus: custom pricing via sales

Published (E. Plus): $30,000/yr
Katie asks for 15% off: $25,500/yr
Katie asks for 20% off: $24,000/yr
Floor: TBD based on final cost model

​

Open Questions

1. What are the right account limits per tier? Currently anchored at Max=5, Enterprise=50, Enterprise Plus=200+. But if we learn from the market that a typical Max user manages 25 accounts, the entire tier structure needs recalibration. The model should be parameterized so we can adjust without redesigning.
2. Parameterized model for recalibration. The pricing formula should use tunable parameters:
   BASE_ACCOUNTS = { max: 5, enterprise: 50, enterprise_plus: 200 }
   BASE_SEATS    = { max: 1, enterprise: 5, enterprise_plus: 10 }
   BASE_PRICE    = { max: $199/mo, enterprise: $1,000/mo, enterprise_plus: $2,500/mo }
   ADDON_ACCOUNT = { max: $8/mo, enterprise: $5/mo, enterprise_plus: $3/mo }
   ADDON_SEAT    = { enterprise: $100/mo, enterprise_plus: $80/mo }
   
   If we discover Max users need 25 accounts, we have three levers:
   • Expand base, keep price: BASE_ACCOUNTS[max]=25, price stays $199 → more generous, competitive
   • Expand base, raise price: BASE_ACCOUNTS[max]=25, price goes to $299 → captures value
   • Keep base, lower add-on rate: ADDON_ACCOUNT[max]=$3 → gradual expansion without cliff
3. What are the actual Stripe metadata values for max_accounts per tier? The code enforces account limits via get_max_accounts_for_tier() in stripe_product_service.py, but we need to verify the current Stripe configuration matches the model.
4. Is S × A the right formula, or should it be sublinear? Not every seat touches every account. In practice, planners are assigned account subsets. Pure S × A may overstate compute for large agencies where each planner manages 20-30 accounts, not all 200. But read-only users (analysts, managers) querying across all accounts push it back toward multiplicative.
5. How do we handle the in-house brand edge case? 10 seats on 5 accounts = 50 CU, same as 1 seat on 50 accounts. Are they really equivalent in system load? The in-house team may generate more per-account compute (10 people drilling into the same 5 accounts all day).
6. Should add-on rates be published or internal only? Publishing makes pricing transparent but reduces negotiation flexibility. Keeping them internal means custom deals require a sales conversation. Current leaning: keep internal for sales tool.
7. What is our actual cost floor per CU? We know tool calls cost almost nothing, but at enterprise scale (200 accounts, 10 users), what are the real costs? Ad platform API calls, data storage for 12-month retention, LLM inference for cross-account operations, MCP server compute. Need to quantify so we have a true floor for negotiations.
8. **Enterprise Plus at $30K — is that the right anchor?** For an agency like Katie managing$7-15M/yr in ad spend, $30K is 0.2-0.4$20-24K) to close the first few deals. The published $30K gives us room to offer that as a concession.

​

Appendix: Consumer Plan Reference

• One clear unit (tool calls) with transparent $/unit
• Each tier step has obvious value math (“4x calls for 2x price”)
• Account limits create natural upgrade triggers
• “Unlimited” is bounded by account caps (practical ceiling)