Tenant provisioning

Provisioning is what happens between “the customer bought it” and “the customer can use it”: creating the tenant, seeding configuration, applying entitlements, inviting the first admin, and connecting it back to the billing record.

In a self-service motion this must be instant and unattended. In a sales-led motion it may involve data migration and configuration, but the mechanical part — tenant exists, plan applied, access granted — should still be automatic.

Deprovisioning is the half everyone forgets

Provisioning gets built because nothing works without it. Deprovisioning gets deferred, and the results accumulate quietly:

• Cancelled customers whose tenants keep running and keep costing infrastructure.
• Downgraded customers still using features they no longer pay for.
• Trial tenants that never expire.
• Data retained past what the contract and your privacy policy allow.

The link back to billing

Provisioning is only reliable if it is driven by subscription state rather than by a one-time signal at signup. “Create the tenant when the deal closes” is easy; “keep the tenant’s configuration matching the current subscription forever” is the actual requirement, and it has to survive upgrades, downgrades, seat changes, pauses, renewals and cancellations.

When the subscription is the source of truth and provisioning reacts to changes in it, that consistency is structural. When provisioning is triggered by a webhook at signup and never reconciled again, drift is guaranteed — it is only a question of how long before someone notices.