Preview programs have changed character. What used to be an opt-in trial of an isolated capability is now a routine release channel, with features entering preview, accumulating production usage for a year or more, and then graduating, changing shape or disappearing. Enterprise customers participate because the alternative is waiting, and because the feature is frequently the reason the platform was selected.
The contractual treatment has not kept pace. Preview terms are generally drafted as a comprehensive carve-out: no service level, no support commitment, no warranty, modification or withdrawal at will, limited liability, and broad rights over feedback. That allocation is reasonable for an experiment and increasingly misaligned with how previews are actually used.
This article looks at what the carve-out should and should not include, why withdrawal notice is the term that matters most, how feedback and data-use rights in preview terms can exceed those in the main agreement, and what to ask for on graduation pricing while the provider still wants your adoption.
What the carve-out usually covers
Reading a preview clause against the main agreement is the useful exercise, because the carve-out is defined by what it removes rather than by what it says.
- Service levels, removing availability commitments and credits for the preview capability, and sometimes for anything that depends on it.
- Support, excluding the feature from response time commitments and routing issues to a community or best-efforts channel.
- Warranties, disclaiming conformity to documentation, which also weakens any remedy based on the feature not working as described.
- Change control, permitting modification, restriction or withdrawal without the notice that applies to generally available services.
- Liability and data rights, capping liability and in some agreements broadening the provider’s rights over feedback and usage data.
The item to examine most closely is whether security, confidentiality and data processing terms remain in force. In well-drafted agreements they do, and the carve-out is limited to performance and availability. In others the preview sits outside the security addendum entirely, which materially changes whether production data can be used. This is a question with a one-line answer that very few customers ask.
Excluding a preview feature from service levels and warranties is normal commercial practice. Excluding it from the security and data processing commitments is a different proposition, and if the clause does both, the second one is the negotiable item.
Five things worth negotiating
Preview terms are often presented as non-negotiable standard terms. In practice the following asks are modest, and a provider seeking enterprise adoption of a preview has a reason to accommodate them.
- Keep security and privacy in scope. Confirm in writing that the security addendum and data processing terms apply to preview features, or agree that production data will not be used.
- Secure graduated withdrawal notice. Ask for a defined notice period once a preview has been available for a stated period, or once your usage exceeds a threshold, rather than withdrawal at will indefinitely.
- Limit the exclusion to the feature. Make clear the carve-out does not extend to generally available services affected by a preview failure.
- Narrow the feedback grant. Exclude confidential information and your own proprietary processes, and limit the provider’s use to improving its services rather than any purpose.
- Address graduation pricing. Obtain a cap, a committed tier or a right to a defined discount if the feature becomes a separately priced product during the term.
A five-step internal control path
Step 1, Build a preview register
Record which previews are enabled, in which tenants and environments, by which team, with what data classification and under which terms. Most organizations do not have this, because enabling a preview is an administrative action rather than a procurement event.
Step 2, Classify by dependency, not by interest
Separate previews being evaluated from previews embedded in a production process. The second group is where withdrawal notice matters, and it is usually larger than anyone expects. The sprawl dynamics are the same ones described in our IT leader’s guide to SaaS vendor contract sprawl.
Step 3, Extract the terms that apply
Pull the preview carve-out, notice period, security scope and feedback grant into structured fields on the agreement record, since preview terms frequently sit in a linked policy rather than in the signed document. Precedence between those documents behaves exactly as described in our note on when the order form and the MSA disagree.
Step 4, Set a review on the dependency list
Review production-dependent previews quarterly against provider roadmap communications, and maintain a documented fallback for each. A fallback identified in advance is a decision, while one identified after a withdrawal notice is a project.
Step 5, Raise the terms at renewal
Bring the preview register into the renewal conversation, since by then the provider knows which previews you depend on and adoption is a demonstrated fact rather than a hypothetical. That is the moment notice periods and graduation pricing are most obtainable.
See carve-outs tracked as contract data
Walk through exclusions, notice periods and linked policy terms held on the agreement record.
Why the linked policy matters as much as the contract
Preview terms are rarely in the signed agreement. They usually live in an online policy incorporated by reference, which the provider can update unilaterally, and which may itself point to a deprecation policy and a security addendum that update on their own schedules. The practical consequence is that the terms governing a preview feature can change without any contract amendment and without any notification to the customer. Recording the policy version in force at signature, and checking it periodically against the live version, is the only reliable way to know what currently applies. This is the same discipline required for incorporated service level and support policies generally, and it is one of the clearest arguments for treating referenced policies as contract data rather than as web pages.
The asymmetry is sharper than it first appears. A provider updating its preview policy is making a product decision, documented internally and communicated through release notes that enterprise customers rarely read in full. A customer relying on the previous version has no notification entitlement, because the incorporation clause usually permits updates on posting. The negotiable mitigation is modest and often granted: a commitment to notify named contacts of material adverse changes to incorporated policies, with a defined period, and a right to terminate the affected service if the change is material. Neither obliges the provider to stop changing its policies, and both give the customer a window in which to respond.
Preview terms against generally available terms
The table below contrasts the typical treatment of a preview capability with the equivalent generally available service, and flags the position worth negotiating.
| Term | Generally available | Typical preview | Risk if unchanged | Position to seek |
|---|---|---|---|---|
| Availability SLA | Committed with credits | Excluded | No remedy for outage | Accept, but limit to the feature |
| Support | Response time commitments | Best efforts | No escalation path | Named contact for enterprise previews |
| Security terms | Addendum applies | Sometimes excluded | Production data exposure | Confirm addendum applies |
| Withdrawal | Deprecation policy notice | At any time | Unplanned migration | Graduated notice after a period |
| Feedback rights | Narrow or absent | Broad perpetual grant | Unintended disclosure | Exclude confidential information |
Preview programs are a reasonable bargain. The customer gets early capability and influence over direction, the provider gets validation before committing to support obligations. The bargain stops being reasonable when the carve-out written for an experiment continues to govern a feature that has become part of how the business runs, and the only reliable way to notice that transition is to keep a register of what is enabled and on what terms.
For related guidance, see Auto-renewal clause risk in enterprise SaaS contracts, Open source license clauses in customer contracts and Customer reference and logo use rights clauses.
