Skip to content
Notifications
Clear all

Thoughts on the new data residency add-on? The pricing is opaque.

4 Posts
4 Users
0 Reactions
1 Views
(@fionac)
Estimable Member
Joined: 1 week ago
Posts: 61
Topic starter   [#8752]

Hi everyone. I've been reviewing a new contract for our event management platform, and there's a new data residency add-on that's giving me pause. Our company is starting to expand into new regions, and this clause is becoming relevant for the first time.

The sales rep said it was a "premium feature" for compliance, which I understand. But when I got the draft, the pricing section just says "additional fees apply based on region and data volume." There's no schedule, no defined tiers, and no examples. It feels like we'd be agreeing to an unknown future cost.

Has anyone else negotiated this kind of add-on? Specifically:
- What kind of pricing structure did you end up with? Was it a flat fee, per-user, or based on storage?
- Were you able to get clear overage definitions for data volume?
- Did you find any auto-renewal language tied to this add-on that was different from the main agreement?

I'm trying to learn what's reasonable to ask for before we go back to the table. I'm concerned about signing something where the fees could scale unpredictably. Any experiences or clauses you pushed for would be really helpful.



   
Quote
(@jamesk)
Estimable Member
Joined: 1 week ago
Posts: 80
 

That "additional fees apply based on region and data volume" line is a major red flag. We absolutely refused to sign until we got an explicit pricing appendix.

Our add-on ended up being a flat monthly fee per region, with a clearly defined data volume threshold per region (they called it a "compliance bucket"). Anything over that was a predictable per-GB overage charge. The key was tying the volume definition to the data the feature actually processes and stores, not all platform traffic.

Push hard on the auto-renewal part too. We found they'd tucked in language that the add-on would auto-renew at "then-current" list prices, which was a non-starter. Got it amended so any renewal uses the same pricing structure for at least a year. Good luck



   
ReplyQuote
(@amandaf)
Estimable Member
Joined: 7 days ago
Posts: 73
 

Spot on about tying the volume to the actual feature data. The sales term "compliance bucket" is useful for negotiation, but you have to lock down the exact technical definition in an appendix. We've seen vendors define that bucket so broadly it included cached log files.

That auto-renewal clause is the real sleeper. "Then-current" list prices is unacceptable. We also pushed for and got language that requires a 90-day notice and a fixed price cap for any renewal term, not just the first one. If they won't agree to a cap, walk away.


—AF


   
ReplyQuote
(@integration_tinkerer)
Estimable Member
Joined: 3 months ago
Posts: 104
 

Yeah, the technical appendix is everything. We actually built a quick script to pull our own API logs and map what *would* fall into their proposed "bucket" before we signed. Showed them their own definition would have tripled our cost based on our data flow. They had to rewrite it.

The >fixed price cap for any renewal term is the dream. In my experience, they'll fight harder against that than the initial pricing. If they balk, a solid fallback is to link the annual increase to a specific, public index like the CPI. Stops them from inventing a 30% hike because they feel like it.



   
ReplyQuote