Everyone's talking about list price discounts, but that's just the appetizer. The real bill comes later with Ping. If you're in procurement, your job is to avoid the surprise invoices that hit 18 months after the champagne-popping "deal."
Based on painful experience, here are the areas where costs love to hide:
* **The "Core vs. Everything Else" Game:** You'll negotiate the core PingFederate or PingOne license. Then you find out you need PingDirectory (or PingDirectory Proxy) for your user store, PingAccess for fine-grained authorization, and maybe PingIntelligence for API security. Each is a separate SKU, often with its own user-based or throughput-based pricing model. Ask them to map your *entire* required architecture to a line-item quote **now**.
* **User Counts & Non-Human Identities:** They'll quote you for your employee count. But what about customer identities (CIAM)? What about service accounts, API clients, and IoT devices? The definition of a "user" or "entity" in the contract is everything. If it says "any entity that receives a token," you're on the hook for every microservice and bot. Get explicit exclusions written in.
* **The Professional Services Black Hole:** Their sales engineer nods and says your team can handle the implementation. Then you read the fine print: certain critical features (custom adapters, complex high-availability setups) are "recommended" to be done by their PS team at $250+/hour. Ask for a clear matrix of what's included in standard support and what triggers a professional services engagement.
* **Annual Support & Maintenance Escalators:** The 20% (or so) annual fee isn't static. Many contracts bury a 3-7% annual *increase* on the support fee itself, on top of any user-count growth. This compounds. Negotiate a cap on the support escalator for the term of the agreement.
* **Decommissioning Costs:** This one's a classic. When you eventually migrate off (and you will), extracting your configuration and data can be a nightmare. Some vendors charge exorbitant fees for "decommissioning support" or tools. It's not a current cost, but you need to know the exit toll booth's price before you get on the highway.
Bottom line: Treat the sales rep's initial quote as a fictional novel. Your job is to write the non-fiction appendix. Get everything—definitions, dependencies, service boundaries—in writing before you even talk about final pricing.
Just my 2 cents
Trust but verify.
That "Core vs. Everything Else" game you mentioned is brutal. It happened to us with another vendor. They sold us the shiny platform, but the basic data sync tools were an extra module that cost almost as much.
What's the best way to actually get that line-item quote upfront? Do you just demand a full architecture review from their solution engineer before the procurement team even gets involved?
You've nailed the issue. "Demanding" a full architecture review is the right spirit, but your timing is even more critical.
Get a solutions architect involved early, but make it a formal deliverable tied to a workshop. Before the sales rep even connects you, insist on a paid or scoped discovery session. The output has to be a detailed document mapping your specific use cases (like syncing HR users to the directory, or exposing apps to external partners) to required components, complete with placeholder SKUs.
If they push back, it's a huge red flag. We learned the hard way that vague diagrams in a slide deck become "optional add-ons" later. That line-item quote is your only real map.
Cheers, Henry
Oh, that point about non-human identities is so real. We got absolutely torched by that once.
Our contract was based on "named users," which sounded safe. But then our dev team spun up a few dozen service accounts for automated testing, and each one was considered a unique entity that could be provisioned. The bill for those "users" was a nasty shock.
So what about IoT? If a smart sensor needs to authenticate, is that an "entity" under their definition? Asking for explicit exclusions is the only way to sleep at night.
Words matter
That's a nightmare scenario. Service accounts can multiply overnight, and you're right to worry about IoT.
We got caught by "unique API calls" counting as an identity event once, which felt similar. It wasn't a person, just a system check. I'd push to define "user" in the contract as exclusively a human employee, contractor, or customer. Everything else, especially automated processes and devices, needs a separate, capped pricing tier.
Has anyone successfully gotten IoT devices explicitly excluded as named users?