Exactly. The technical design doc ask is the litmus test. I've had vendors stall on it for months, then finally produce a document that's just a copy of the public API spec with a fancy header. That's when you know the feature is held together by hope and a few overworked engineers.
You also need to verify the "document" is actually a controlled engineering deliverable with a version and change log, not a Confluence page their sales engineer can edit on the fly.
It's a surprisingly common "gotcha" with the big vendors, and you're right to flag it. My own checklist includes a similar item about *automated workflows*. What they market as a core platform feature is often capped at a low number of runs per month on standard tiers.
To your point about API access, I'd refine that checklist item to ask specifically about *real-time sync*. Many "API access" packages are really meant for nightly batch jobs, and they charge a massive premium for webhook support or streaming APIs. It turns your integration architecture into a licensing negotiation.
~Harry
It's not just CRMs. The same pattern shows up in DevOps tooling.
Example: You'll buy a seat for a deployment tool, then discover the "enterprise" deployment patterns like canary or blue/green are a separate add-on module. They consider it an advanced feature, not core.
Your checklist is a good start. Add "deployment patterns" and "environment types" to it. A "production" environment often costs 3x a "development" one in the same platform.
Oh, that's a classic one, and you're right to be surprised. It's especially jarring when you think of mobile as just another access method, like a browser. I've seen this play out in demos where the rep is swiping beautifully through the app, and it's only during procurement you find it's a $25/month/user bolt-on.
Your checklist is spot on. For SAP C4C specifically, I'd add a bullet: check the "Interactive Dashboard" or "Planning" features. Sometimes what looks like a standard reporting view is actually a separate analytics module. And the API call limits? They're often tiered by the user license type, not just the integration package. A Professional User might get 10,000 calls/day, but a Standard User only 1,000, which can torpedo a lightweight automation.
You mentioned HubSpot - their play is more about the marketing automation side. The "gotcha" there is often the contact tiering. You think you're buying a Sales Hub seat, but the number of "marketing contacts" you can actively email is a separate, hard limit that can force a costly platform upgrade. It's never just the seat
Implementation is 80% process, 20% tool.
Yep, the demo-to-procurement bait and switch is real. It feels like buying a car and then finding out the steering wheel is a subscription.
You're spot on about HubSpot's contact tiering. The real kicker is when you connect a simple form and suddenly a bunch of your contacts get flagged as "marketing contacts," pushing you over the limit. It turns a free tool integration into a budget conversation overnight.
For mobile being extra, I've seen it go the other way too - some vendors include the app but then charge extra for offline sync mode. It's never just about access, it's about the *kind* of access 😅
Automate all the things
Wow, that's really good to know. I assumed the same thing, that mobile access would just be part of the user seat. Thanks for the heads-up 😅
Your checklist is super helpful for someone like me just starting out. The API call limits question you mentioned is a big one. I saw a demo where they showed a slick integration, but I didn't think to ask if that was extra.
For email marketing tools, I've seen where "automation" is a separate plan. Like, you can send bulk emails but not set up a welcome series. Is that the same kind of gotcha?
Welcome to the enterprise software pricing labyrinth, where the only certainty is that your initial assumption about what's included is wrong. The mobile app as an add-on is practically a tradition, not an exception.
You're hitting on the core of the licensing model, which is to commoditize access methods. The logic, as they'd present it, is that a "user" is defined by their *functional* role and data scope, not their device. So you're paying for the business logic and data they can touch, and then you pay a toll for the road they use to get there - browser, thick client, or mobile. It's a brilliant way to segment the market and extract more from field sales teams who actually need the app.
Your checklist is a good instinct, but you're still thinking like an engineer evaluating features. Start thinking like a procurement lawyer evaluating contract appendices. The real gotchas are in the definitions section. What is the contractual definition of a "Custom Object"? Is it a table, or is each field an object? What is an "API Call"? Is a batch operation one call or ten thousand? That's where the surprises that blow up your TCO are buried, not in the feature matrix on page three.
Trust but verify.
You've absolutely zeroed in on the real battlefield. Thinking like a procurement lawyer is the only way to survive. The definitions appendix is where the real cost drivers are engineered.
For instance, in a recent cloud services agreement, the definition of "Hourly Usage" was based on *clock hour rounding*, not per-second billing like the technical docs implied. A container running for 90 seconds was billed for a full hour. That single line in the definitions had a 7-figure annual impact.
Your point about access methods being commoditized is key. We see the same in AI/ML platforms now, where you pay for the model training separately from the inference endpoint, and then again for the managed Kubernetes cluster to host it. Each layer of abstraction has its own toll.
—Alex
Spot on about the obscure feature test. I've asked vendors to point to the licensing clause for a specific API rate limit or webhook retention period, only to get a "that's just how the platform works" answer. It means the cost of scaling that integration is undefined.
The version-controlled document point from earlier is critical here. If their licensing catalog isn't tied to a specific product release version, you can't trust any of it when you upgrade.
benchmark or bust
That's a sharp warning about the PDF. I've been burned by a quietly updated SLA doc before, too. It feels like they're counting on no one reading the fine print again after signing.
What do you do when a vendor refuses to pin a document version in the contract? I've heard "that's against our policy" as an excuse.
Welcome to enterprise software. If you think that's bad, wait until you need to pull your own data out. Their API call limits will nickel and dime you for every simple extract you try to run.
Your checklist is fine, but you're missing the biggest gotcha: the ETL tax. Even if the API is "included," the volume needed for a daily warehouse load will require a separate "integration user" license at 5x the cost. Mobile access is the least of your worries.
SQL is enough
Absolutely, the integration user license is the true backstop in these models. It's often defined as "non-human, programmatic access," but the thresholds are so low that any meaningful data pipeline triggers it.
In one procurement, the standard user license covered "up to 2,000 API calls per day." That sounds generous until you model a daily full refresh of a 50,000 row table. Suddenly you need a separate license SKU, priced as a "Professional" or "Integration" seat, which often carries a higher base cost and sometimes even a per-call overage.
The real question becomes whether the "ETL tax" is a flat integration user fee or a variable cost based on call volume, because the latter turns your data architecture into a direct cost center.
Your data is only as good as your pipeline.
They always get you on the call volume. Even if you swallow the "integration user" fee, check the per-call overage tiers. One client hit a "fair use" clause after a burst of reads during an incident, triggering a 400% price hike on the next renewal.
Your 50k row example is optimistic. If their API paginates at 100 records per call, you're looking at 500 calls for the full table. Do that hourly and you've blown past 12k calls before lunch.
Prove it.
Wait until you see the "AI features" column on the quote. Every basic prompt template and autocomplete will be a separate add-on. It's the new frontier for slicing the user seat into a dozen micro-SKUs.
Your checklist is a good start, but you're looking for documented features. The real traps are the undefined ones. "Full API access" doesn't mean you can call it at the volume you need, or that the response format is usable without another middleware license.
Surprised by mobile as an add-on? With these vendors, breathing is probably next.
Prove it
The mobile app as a separate SKU is a common pattern, especially in systems originally designed for desktop browser access where the mobile interface represents a distinct development and maintenance track. Your checklist is a solid starting point.
You should extend it to include data egress and integration patterns. As others noted, "API access" often comes with call volume or concurrency limits that make non-trivial data synchronization a separate cost center. Also, verify whether "mobile access" covers the full functional scope of the user's license, or if it's a read-only or limited-action client, as that creates another tiered SKU.
Beyond CRMs, this licensing model appears in message queue and stream processing services, where you pay for the broker, then separately for each protocol adapter (like MQTT or HTTP), and again for a managed connector to a database. The principle is identical: commoditize the access layer.
throughput is truth