GTM Segmentation — Billing Rail, Maturity Personas & 3PI vs Stand-Alone¶
Date: 2026-06-15
Companion to: AWS_MARKETPLACE_LAUNCH_GAP_AUDIT.md
Purpose: Capture the two separate decision trees that govern Vellocity's GTM —
(1) how a customer is billed and (2) which product/motion they get — so they are not
conflated. They are correlated but not identical.
Three axes that must not be merged¶
| Axis | What it decides | Driven by |
|---|---|---|
| Billing rail | How money moves — Stripe vs AWS Marketplace (consolidated onto the buyer's AWS bill via entitlements + BatchMeterUsage) |
Whether the customer holds an AWS account, plus their preference |
| Pricing model | What you charge — subscription, flat + consumption, pure consumption | Value metric + buyer-predictability needs |
| Segment / overlap | Which product surface & motion — and whether you collide with an existing Build vendor | The customer's maturity persona, and (for sellers) 3PI vs self-managed |
The billing rail is one bit (AWS account holder?). The product/motion is the full ladder. Wire them separately.
Decision Tree 1 — Billing rail¶
The AWS Marketplace rail requires only that the customer be an AWS account holder (a buyer) — not a partner and not a seller. The boundary therefore cuts through the lowest maturity persona, not between personas.
| Maturity persona | AWS account? | AWS Marketplace rail | Rail default | Why |
|---|---|---|---|---|
| Not on AWS at all | No | ❌ Not possible | Stripe | No AWS account to bill |
| AWS customer only (buyer, not partner) | Yes | ✅ Eligible | Stripe or AWS — their choice | Already an AWS buyer |
| AWS partner, not a seller | Yes | ✅ Eligible | AWS billing | Eligible + commit benefit |
| AWS seller (listed) | Yes | ✅ Eligible | AWS billing | Eligible + commit benefit |
Rule: not on AWS → Stripe · AWS account holder → offer AWS Marketplace.
Prefer the AWS rail for partners/sellers (levels 2–3): Marketplace spend retires their EDP / committed spend — a buyer benefit, not just an option (launch-checklist #6, #34). Pitch it as "counts against your AWS commit." The "AWS customer only" persona gets a genuine choice; "not on AWS" gets Stripe only.
Do not hard-wire the rail to the persona. Key it on "has AWS account + wants consolidated billing," offered at checkout. Maturity drives the product, not the rail.
Decision Tree 2 — Product surface & motion (the maturity ladder)¶
| Maturity persona | What Vellocity offers | Motion |
|---|---|---|
| Not on AWS / AWS customer only | Not yet listed; future-pipeline. Help them become a partner/seller; Market education | Nurture / top-of-funnel |
| AWS partner, not a seller | Path to first listing (Build) + GTM foundation | Activation: get-listed + GTM |
| AWS seller — self-managed (~80%) | Build + Market — surface the built listing/metering/entitlement layer; "list, meter, and market in one place" | Direct / self-serve + AWS field; wedge = MMP/metering pain |
| AWS seller — 3PI customer (~20%) | Market only — co-sell, content, pipeline; hide the Build layer | Complement; co-market with Tackle/Clazar/Suger |
The 3PI vs self-managed split exists only inside the seller tier. It is a sub-segmentation, not a rung on the ladder.
The "two 3PIs" question — resolved¶
A Tackle/Suger customer who buys Vellocity through AWS Marketplace is not signing onto a second 3PI. They are buying a SaaS billed to their AWS account — like any Marketplace purchase. Metering your own fees does not make you a 3PI. Tackle/Suger are 3PIs because they sit in the customer's path to their own end-buyers (managing the customer's listings, metering, disbursements) — a different layer from "Vellocity charges the customer for Vellocity."
At the billing layer there is no collision. The only real overlap is at the data / Build layer: if Vellocity needs the customer's listing / agreement / metering data (for attribution, co-sell, pipeline), that data already lives in Tackle/Suger.
Therefore the 3PI integration is a data-read interoperability play — not a billing de-duplication fix. Pull the customer's existing Build data where it already lives, rather than forcing them to re-plumb or duplicate it in Vellocity. That is why the 20% never have to choose between Vellocity and Suger.
Pricing model — keep the hybrid¶
The AWS Marketplace rail can carry any model (subscription, hybrid, pure consumption) — the meter
is just BatchMeterUsage; the contract is carried by entitlements. The code already supports
contract + consumption hybrid (config/services.php: subscription plan_mapping and
usage_dimensions).
Pure consumption's weakness is unpredictable buyer cost (launch-checklist #18, #21), which AWS procurement dislikes. Recommendation:
- 3PI segment (~20%): flat subscription / seat — predictable, no billing collision, sold as a Market complement.
- Self-managed segment (~80%): hybrid base + consumption — usage (AI generation volume) scales with value, and you may own more of their stack.
The rail (AWS Marketplace metering) is the right call; the model stays hybrid, not pure consumption.
One-line summary¶
Rail = "do they hold an AWS account (and want commit-eligible billing)?" Product/motion = where they sit on the maturity ladder, and—if a seller—3PI vs self-managed. The 3PI integration reads Build data; it does not touch billing.