Template for growing from initial SKU to second SKU to enterprise license within a single federal agency. NRR targets and expansion trigger criteria fill in once the first account is live.
Ch 4 of Shrink-Wrap It argues that hidden IP already exists in delivery history. The same principle applies to expansion: the second SKU is not a new product pitched at an existing customer. It is an additional problem the customer already has, solved by IP that NorthAI already has. The expansion conversation is, "You already use the authentication layer. Here is the posture dashboard that sits on top of it." Not a cold pitch. An extension of existing value.
In federal accounts, this distinction matters legally as well as strategically. Adding a new CLIN under an existing contract is faster and less risky than a new contract action. The expansion playbook stays inside the existing contract vehicle wherever possible.
| Stage | Description | Contract mechanism | Revenue signal |
|---|---|---|---|
| Stage 1: Initial SKU | First product deployed and in go-live. Authentication layer or posture dashboard (per sku-launch-plan-v0). CLIN 0001 subscription active. | CLIN 0001 (subscription) + CLIN 0002 (onboarding) under original contract | [Baseline ARR: user count x CLIN 0001 rate] |
| Stage 2: Second SKU | Second product line added to the account. Triggered by 3-customer threshold on Stage 1 (see second-sku-spec-v0). Examples: ConMon dashboard as optional module; ICAM integration layer. | Contract modification adding new CLIN 0005 (second SKU subscription) under existing contract; no new competition required if within original scope or below SAT | [NRR target: 125-140% of Stage 1 ARR] |
| Stage 3: Enterprise license | Agency-wide license replacing per-user billing once adoption reaches full agency footprint. Tiered pricing negotiated under enterprise CLIN. | Enterprise CLIN modification; may require new competition if scope materially changes or value exceeds original contract ceiling | [NRR target: 180-220% of Stage 1 ARR] |
Net Revenue Retention (NRR) is the percentage of recurring revenue retained from an existing customer cohort, including expansions and net of contractions and churn. The targets below are benchmarks, not guarantees. They populate with actual numbers once the first account is live for 12 months.
| Metric | Baseline (Month 12) | Target (Month 24) | Target (Month 36) |
|---|---|---|---|
| Account NRR | [100% = no expansion, no churn] | 120-130% | 140-160% |
| User expansion rate within account | [Baseline user count at go-live] | +25-40% user growth | +60-100% user growth or enterprise license conversion |
| Second SKU attach rate | 0% (first SKU only) | 30-50% of accounts with second SKU | 60-75% of accounts with second SKU |
| Gross revenue retention | [100% = no contractions] | 95%+ | 95%+ |
Expansion conversations should not be initiated until the account meets a minimum health threshold. Premature expansion conversations damage trust with a federal ISSO who is still validating the initial deployment.
| Trigger | Minimum threshold | Signal source |
|---|---|---|
| Time since go-live | At least 90 days | Go-live confirmation date |
| User adoption | At least 60% of provisioned users active in last 30 days | Usage metrics from product |
| Open issues | No P1 or P2 open tickets; no open POA&M items past due | Ticket system + ConMon log |
| ISSO relationship | ISSO has confirmed authorization posture in writing at least once since go-live | Written confirmation email |
| Agency interest signal | PM or ISSO has asked about additional capabilities at least once (organic signal) | Meeting notes or email |
The expansion conversation is structured, not a pitch. It follows this sequence:
Enterprise license discussions are appropriate when at least three of the following are true: