Short answer: Customer success platform contracts need six protections that generic SaaS negotiation advice does not cover: derived-data portability, AI data use, AI usage metering, the definition of a billable account, who may change the scoring model, and the timing of the data behind the score.
One of the largest customer success platforms captures your health scores weekly and monthly. Not on every change.
So the account that slid to red on Tuesday and recovered by Friday never happened, as far as your history is concerned. You can export every company, contact, renewal date and CSM assignment, and still have no record that the week was ever in trouble.
That is not a product flaw. It is a design choice, documented in public, and it is the kind of thing a standard software contract will never surface for you.
Auto-renewal windows, uplift caps and notice periods still matter, and procurement should still review them. Those clauses are well covered elsewhere. They are also not what makes this purchase different.
The difference is that a customer success platform does not simply store your data. It calculates on top of it, keeps a history of those calculations, acts on them automatically, and increasingly passes your customer conversations through a model. Each of those creates a contractual question that seat-based software guidance never had to answer.
Everything below is checked against published vendor terms and documentation, quoted directly, and dated. Where a vendor publishes a genuinely strong clause, it is quoted so you can hold the others to it.
The six terms at a glance
| CONTRACT PROTECTION | THE QUESTION TO RESOLVE BEFORE SIGNING |
|---|---|
| Derived data on exit | Which calculated history can we take, and at what granularity was it ever captured? |
| AI data use | What may the vendor and its model providers do with our customer conversations? |
| AI usage metering | What consumes the allowance, including work no human started? |
| The billable unit | Which records create a charge, and when is the count taken? |
| Configuration rights | Who may change the scoring model, and what do we become responsible for by changing it? |
| The four clocks | How long until a source change becomes a score, a report and an action? |
Each needs two things: a commitment written into a document that binds, and a test you run before signing. A demonstration is not an obligation. A clause is not proof the software can do it.
1. What happens to your health-score history when you leave?
The risk: you own the inputs and lose the output.
Your CRM gave you the company names, the contacts, the renewal dates. Those come back out. The scores the platform calculated from them are a different kind of data, and they are the part you cannot rebuild.
Two published facts show why this needs its own clause.
Granularity is decided by the product, not by your contract. Gainsight's documentation for how Scorecard Snapshot works states that Snapshot "captures scores in two frequencies; Weekly and Monthly". It stores the final score of a week and the final score of a month, and the same page sets out the mechanism: the scheduler runs every day at 11.30 pm UTC, and each run replaces the week's entry with the latest score until the week closes.
Read that as a buyer and the implication is clear. Intra-week movement is written and then overwritten. An account that fell to red on Tuesday and recovered by Friday closes the week looking healthy, and the history keeps the healthy number. Snapshot is enabled by default and Gainsight recommends against turning it off, so this is not a misconfiguration. It is the design. Before you negotiate the export, establish what was ever recorded.
A good exit clause exists, and it still has a gap. Planhat's Terms of Service, last updated 29 September 2026, commits at Section 5.7 that it:
"will make export functionality available throughout the Subscription Period and for up to thirty (30) days following its expiry or termination, will not delete Customer Data during that period, and will not charge for the retrieval or export of Customer Data."
A thirty day window, no deletion inside it, no charge for retrieval. That is a strong, specific commitment and a fair benchmark to put to any vendor.
Now the gap, which is the useful part. The same section scopes the right to export "in accordance with the export functionality and formats described in the Documentation." The contract guarantees the process. The contents are defined by whatever the product currently exports. If calculated history is not in that export today, a thirty day free window does not put it there.
That distinction is the whole of this term. Negotiate the dataset, not only the window.
What to put in writing
Name the objects, not the file format:
- Account identifiers, including parent and child relationships
- Historical overall scores, with their original dates
- Historical component or measure values
- The recorded explanation of score drivers, where one exists
- Notes, tasks, success plans and custom fields
- An explicit list of what is excluded
Then settle the access window, the formats, whether retrieval is self-serve or a priced service, and what happens to the data afterwards.
You do not need the vendor's algorithm. You need the results it produced for your business.
The test
Ask for five test accounts carrying several score changes each, then export them and try to rebuild the history outside the platform. An export containing only today's score fails. An export at weekly granularity when you assumed daily is not a failure, but it is a fact you want before signing rather than after.
Related RFP requirements: 8.4 exit export and deletion, 7.5 historical migration.
2. What may the vendor's AI do with your customer conversations?
The risk: the AI page on the website is not the clause in your agreement.
A customer success platform sees material an ordinary productivity tool never touches: a champion saying the budget is gone, a note about a reorganisation, a support thread about a team that stopped logging in. Put a model over that and the question is no longer whether the vendor uses AI. It is what each party is permitted to do with the content.
Two vendors publish answers precise enough to quote, which makes them the standard to hold others to.
Planhat's terms state it flatly:
"Planhat will not use Customer Data to train, fine-tune or improve any artificial intelligence or machine learning model, and will not permit any sub-processor to do so. Planhat does not use Customer Data or Output of one customer to generate Output for any other customer."
Vitally names the infrastructure and the providers. Its AI Copilot documentation states that its AI features run on AWS Bedrock, that "AWS is the only subprocessor involved in handling AI-related requests," and that model providers, naming Anthropic and Cohere as examples, "do not have access to your prompts, data, or completions. Data is not made available to them for training or reuse."
Both are statements by those vendors about their own services as published in October 2026. Neither tells you what any individual customer has signed. They do show what a specific answer looks like, which is the point: if a vendor cannot match that level of precision in a document that binds, you have found something worth resolving.
What to put in writing
| QUESTION | WHAT THE DOCUMENT MUST SAY |
|---|---|
| Training | May customer data, prompts or outputs train, fine-tune or improve any model |
| Evaluation | May the content be used to evaluate or improve vendor systems |
| Subprocessors | Which providers process the content, and how are changes notified |
| Retention | How long are prompts, outputs and logs kept |
| Region | Where does inference happen |
| Controls | Which features can be switched off, and what breaks when they are |
Treat "training" as a narrow word. A prohibition on training does not by itself prohibit retention, logging, human review or aggregate analytics. Ask about each.
The test
This one is a document review, not a demo. Hand the proposed agreement, DPA, incorporated AI terms and subprocessor schedule to whoever owns privacy, and ask them to point at the clause for each row above. No product demonstration can establish any of it.
Related RFP requirement: 6.2, AI training and data-use verification.
3. What actually consumes the AI allowance?
The risk: the meter runs when nobody is logged in.
A sales engineer shows you an account summary and tells you the included allowance is plenty. Then you go live, and a scheduled job starts evaluating accounts every morning, an agent re-runs when it fails, and a playbook triggers analysis on every status change. None of that is a person clicking a button.
Planhat's terms are the clearest published statement of how this works. Section 6.3, headed Scope of Use Overage and AI Usage:
"AI usage is consumed whether an operation is initiated by an Authorised User or by a schedule, event, background process, Third-Party Tool or Agent, and Customer is responsible for all AI usage in its account, including where Customer's AI Configuration causes operations to repeat, loop or escalate."
Read that twice before you agree to any allowance anywhere. It is not unusual; it is unusually well disclosed.
The same section also sets out two things a buyer should want on both sides of the table. Overage is charged "at its then-current rates" unless the order says otherwise, which is uncapped language of exactly the kind to negotiate. And Planhat commits that it "makes available information on AI usage by AI Feature, by Authorised User and by Agent, and the ability to suspend an Agent."
That last sentence is the benchmark. Visibility broken down by agent, plus a kill switch. If a vendor meters your AI but cannot show you consumption by source or stop a runaway agent, that gap is the negotiation.
What to put in the order form
- The included allowance and the metering unit for each AI capability
- Confirmation that background, scheduled and agent-initiated work consumes the same meter
- The rate for additional usage, and whether it is fixed or "then-current"
- Whether unused allowance expires or rolls over
- Consumption visibility, and at what breakdown
- What happens at the limit: hard stop, approval request, degradation, or billing continues
- Whether overage needs prior authorisation
An allowance is not a spending limit. Those are two different protections and you want both.
A sizing sketch, not a benchmark
If a workflow checks 200 accounts once a day and each check consumes one metered unit:
200 × 30 = 6,000 units a month, before retries, summaries or any second operation.
The arithmetic is illustrative. Real consumption depends entirely on how a given platform defines its unit, which is the reason the unit belongs in the order form.
The test
Enable the proposed features in a test tenant. Run a set of manual, scheduled and agent-triggered operations, then reconcile consumption against the published meter. Then approach the limit deliberately and watch what the platform does.
Related RFP requirement: 6.4, AI allowance and overage.
4. Which records actually create a charge?
The risk: the bill grows without a single new hire.
Generic negotiation advice is written around seats. Several customer success platforms are not. Planhat's terms define the commercial envelope this way:
"Scope of Use" means the permitted extent of Customer's use of the Services as specified in the Order Confirmation, including the number of Authorised Users, accounts, any AI usage allowance and any other applicable volume or usage metric
Users, accounts, AI allowance, and any other metric the order happens to name. Which means the order form, not the master agreement, is where your real commercial exposure is written.
So the question is never "per seat or per account." It is which exact records, users or units produce a charge under the plan you were quoted.
Where the ambiguity lives
| RECORD TYPE IN TYPICAL CRM | COUNT |
|---|---|
| Active paying customers | 950 |
| Churned, retained for history | 300 |
| Trials and evaluations | 150 |
| Subsidiary and child records | 100 |
| Total imported | 1,500 |
On a plan including 1,000 tracked accounts, the difference between counting 950 and counting 1,500 is a band change. That should be settled before the import, not discovered in the first invoice.
What to put in writing
Resolve whether the count includes former customers kept for reporting, trials, prospects, archived records, duplicates pending merge, and whether a parent and its children count once or separately. Then fix when the count is taken, whether a temporary spike bills immediately, how you can audit it, and the price of the next band before you commit to this one.
If the vendor prices on seats instead, apply the same discipline to administrators, read-only viewers, dormant accounts and service accounts.
The trap that only exists when you price on accounts
Generic advice tells you to negotiate a cap on price increases. Read how the cap is scoped. Planhat's terms state:
Where the Order Confirmation states the basis on which the Fees will be adjusted at renewal, that basis applies to the first renewal period only, and Planhat's then-current pricing applies to each subsequent renewal period. Any renewal in which the Scope of Use or the length of the Subscription Period has decreased from the prior period will be priced without regard to the prior period's per-unit pricing.
Two things there, and the second is the one nobody writes about.
A negotiated renewal basis can apply to the first renewal only. Everything after that returns to then-current pricing. If you negotiate a cap and assume it is permanent, check which renewals it actually binds.
Shrink, and you lose your unit price. If your Scope of Use decreases, the renewal is priced without regard to what you were paying per unit. On a seat model that bites when you cut headcount. On an account model it bites for a reason specific to this category: your tracked-account count falls when customers churn or get archived, which is to say it falls in exactly the year you can least afford a worse rate. Growing into a better per-unit price is the normal expectation. Shrinking out of one is the clause to read before you sign.
Ask what happens to your per-unit rate if the count goes down, and whether a reduction is permitted mid-term at all. Order forms are frequently non-cancellable during the subscription period, with an early termination fee equal to the remaining fees, so the practical answer is often that you carry the count you committed to until renewal.
The test
Import a sample containing all five record types, then have the vendor show the billable count and explain each inclusion against the contract definition.
Related RFP requirement: 9.1, pricing unit and quoted scope.
5. Who may change the health model, and what do you take on by changing it?
The risk: a change you were shown in week two becomes a priced services request in month six, and a configuration you made becomes a liability you did not price.
Health scoring is never finished at go-live. A signal turns out to be noise, a new product needs its own model, a segment behaves differently. The practical questions are familiar: can an administrator reweight adoption in the enterprise model, does it need a certified consultant, does the change rewrite history or apply forward only, can two models run at once, and does the plan cap how many you get.
There is a second question that generic advice misses entirely, and 2026 is the year it starts to bite.
Configuration is now a liability boundary, not just an admin permission. Planhat defines the term precisely:
"AI Configuration" means the settings by which Customer determines how AI Features operate, including agent definitions, instructions, prompts, rules, guardrails, approval settings, triggers and permissions, but excluding any template, system prompt, guardrail, agent definition or other component provided by Planhat, except to the extent Customer modifies it
Note the sting in the tail. A vendor-supplied guardrail is the vendor's, right up to the moment you edit it. Pair that with Section 6.3 above, which makes the customer responsible for usage when its AI Configuration causes operations to loop, and the shape is clear: the moment you tune a template, the consequences are yours.
The same terms take it further. Planhat states the intended purpose of its AI Features in its documentation and specifies that they are not to be changed into a high-risk AI system, and that:
"Where Customer uses or configures an AI Feature so that it becomes a high-risk AI system, or otherwise modifies its intended purpose to that effect, Customer is the provider of that system and is responsible for the obligations attaching to that role."
For a platform processing customer conversations, that is not theoretical. Planhat's own restrictions prohibit configuring an AI Feature in a way that would be a prohibited practice under the EU AI Act, "including by inferring emotions from biometric data in the workplace." A CS team building sentiment analysis over recorded calls should know exactly which side of that line it is standing on, and which party the regulation then treats as the provider.
Ask every vendor the same question: if we configure your AI, at what point do we become responsible for it, and where is that written.
What to put in writing
Set out which roles may create, inspect, test and publish model changes without contacting the vendor; what support covers defects, integration failures and configuration help; which requests are subscription, which are implementation, and which are priced services; and whether a model change recalculates history or preserves the scores as they stood. That last one decides whether your before-and-after reporting means anything.
The test
Have your own administrator make one agreed scoring change in the proposed environment. Record whether they could inspect the inputs, publish it unaided, see the effect on historical scores, and whether any vendor help, plan limit or charge appeared.
Related RFP requirements: 2.1 score transparency, 2.2 model configuration and recalculation.
6. How long until a source change becomes an action?
The risk: the platform is up and the number on the screen is two days old.
An availability percentage tells you the service answered. It tells you nothing about how long a billing failure takes to become a red account and a task in someone's queue. Four separate processes sit in that path, and a vendor can describe the product as real time while one of them runs on a schedule.
| STAGE | WHAT TO DOCUMENT |
|---|---|
| Source ingestion | Interval from source change to ingestion |
| Score recalculation | Interval before the score reflects it |
| Reporting | Refresh behaviour for dashboards and reports |
| Workflow execution | When the dependent automation runs |
There is a specific trap worth knowing. Where you connect your own model or a third party tool, Planhat's terms state that:
"unavailability of AI Features resulting from the failure, degradation, suspension or rate limiting of a Customer-Connected Model or Third-Party Tool is excluded from any availability target, from the calculation of downtime, and from any service credit or refund."
That is a reasonable position for a vendor to take, and it is also the clause that turns your bring-your-own-model decision into an uncovered dependency. If your health scoring runs through a model you supply, your SLA quietly does not cover the part most likely to rate-limit you. Decide that deliberately.
What to put in writing
For each critical integration, record the connector, the expected refresh behaviour, how failure is detected, who is notified and how fast, and what the vendor does when a component it controls fails. Separate third party outages from failures of the vendor's own connector, ingestion, scoring or automation. Where a refresh time is genuinely business critical, make it measurable and attach a consequence.
Resist the urge to turn every interval into a penalty. Start by making responsibility unambiguous.
The test
Change one controlled record that should move a score, appear in a report and fire a workflow. Capture all five timestamps and compare them against limits you agreed before the test ran. If the vendor cannot say when a stage happens, "real time" is undefined.
Related RFP requirement: 1.2, data refresh and workflow timing.
Where do these terms actually belong?
Not all of it goes in the master agreement. What matters is that each commitment sits in a document that is properly incorporated and survives.
| PROTECTION | USUAL HOME |
|---|---|
| Derived-data export | Data exit schedule or signed amendment |
| AI data use and subprocessors | DPA and incorporated AI terms |
| AI metering and overage | Order form and usage schedule |
| Billable unit definition | Order form and pricing schedule |
| Configuration rights and services boundary | Licensed scope and statement of work |
| Refresh expectations and failure handling | Service schedule or technical exhibit |
An implementation plan, a help centre article or an encouraging email can describe a capability perfectly and bind nobody. Have counsel confirm incorporation, order of precedence, remedies and governing law.
What if the vendor says no?
Some refusals are entirely reasonable. No vendor can guarantee a third party API, export the internals of a proprietary model, or prevent every usage spike your own configuration causes.
A refusal should not disqualify anyone automatically. It should also not evaporate from the record. Write down what you asked for, what they said, what they offered instead, and what it means operationally.
| WHAT YOU ASKED FOR | A REASONABLE LANDING POINT |
|---|---|
| Full historical score export | Agreed score values, components and original dates, excluding algorithm internals |
| No AI overage, ever | Advance notification, a spend control, restricted purchase permission, agent suspension |
| Unlimited model changes | Defined self-serve changes plus pre-priced specialist help |
| Guaranteed integration uptime | Vendor-side monitoring, failure alerts, documented incident responsibilities |
The distinction that matters is between a limitation you accepted and an assumption nobody tested. You can run a good CS operation on a platform with known limits. You cannot plan around something you were never told.
How does this fit with the RFP?
Contract review should not be the first time anyone asks these questions.
Our Customer Success Software RFP Template carries 44 requirements and 17 verification checks, and every term above maps to one of them. The RFP establishes what the platform does and what evidence exists. This stage decides which of those answers becomes an obligation.
The sequence is the point. A demonstration shows observed behaviour. Documentation describes intent. Only the executed agreement creates a duty. Three different kinds of evidence, and the expensive mistake is treating the first as the third.
The contract should protect the intelligence, not just the subscription
A customer success platform earns its place by turning scattered signals into something a team acts on. Give it two years and that becomes part of how the company runs: the history showing when accounts started slipping, the model reflecting your particular customers, the automations deciding who gets attention, the AI reading commercially sensitive conversations.
A generic SaaS contract can be immaculate on renewal dates and price caps and silent on every one of those.
The expensive mistake is rarely overpaying for a customer success platform. It is finding out, in the week you decide to leave, which parts of your customer success operation were never yours to take.
Frequently Asked Questions
- What makes a customer success platform contract different from a standard SaaS contract?
- A CS platform calculates and stores derived customer intelligence, runs automated workflows against it, and often processes customer conversations through a model. That adds five questions a standard subscription never raises: what calculated history you can take with you, what may be done with the content you feed the AI, what consumes a metered allowance, which records create a charge, and who is responsible when your own configuration changes how the AI behaves.
- Can I export customer health-score history when I switch platforms?
- Sometimes, and rarely at the granularity people assume. Gainsight documents that its Scorecard Snapshot captures weekly and monthly scores rather than every change. Planhat contractually commits to free export for thirty days after termination, but scopes it to the formats its documentation describes. Ask which objects and dates are included, then export a sample before you sign.
- Can customer success vendors use my data to train their AI?
- It depends on the vendor and on the documents you actually sign. Planhat's published terms state it will not use customer data to train, fine-tune or improve any model and will not permit a sub-processor to do so. Vitally states that model providers have no access to prompts, data or completions. Both are vendor statements about their own services as published in October 2026, so verify the position in your own agreement and DPA rather than inferring it from a security page.
- Does AI usage get consumed by automation I did not trigger?
- On at least one platform, explicitly yes. Planhat's terms state AI usage is consumed whether an operation is started by a user or by a schedule, event, background process, third party tool or agent, and that the customer is responsible even where its configuration causes operations to repeat or loop. Assume the same applies elsewhere until a vendor says otherwise in writing.
- Are customer success platforms priced per account or per user?
- Both exist, often combined. Planhat defines scope of use by authorised users, accounts, AI allowance and any other metric named in the order confirmation, which means the order form is where your exposure is set. Settle which records count, when the count is taken, and the next band's price before committing.
- Does an uptime SLA guarantee my health scores are current?
- No. Availability says the service responded. It says nothing about ingestion frequency, recalculation timing, report refresh or workflow execution. It may say less than you think: Planhat's terms exclude failures of a customer-connected model or third party tool from availability targets, downtime calculation and service credits entirely.
- When should I start negotiating a customer success platform renewal?
- Earlier than the notice window, because the notice window is a deadline rather than a starting point. Work back from the renewal date and allow time to pull usage data, reconcile the account or seat count you are actually being billed for, run any acceptance test you deferred at purchase, and get security to re-check the AI and subprocessor position if it has changed. The leverage comes from arriving with evidence, and the evidence takes longer to assemble than the negotiation does.
- What happens to our price if our customer count goes down?
- Check this before you sign, because the answer is often not symmetrical with growth. Planhat's published terms state that any renewal in which the Scope of Use has decreased will be priced without regard to the prior period's per-unit pricing. On account-based pricing that matters more than it first appears: the count falls when customers churn, so the clause activates in the year you least want a worse rate. Ask whether reductions are permitted at renewal, what they do to the unit price, and whether any reduction is possible mid-term.
- Which of these should be non-negotiable?
- That is yours to set, and it should be set before vendor answers arrive. A processing region, a specific integration, an export right or an access control may be mandatory for you and irrelevant to the next buyer. The rule worth keeping is not to trade a requirement the business genuinely cannot waive for a discount.
