The Module Expansion Dilemma: When Growth Becomes Liability
ServiceNow expansion is the path every scaling enterprise takes. You start with IT Service Management (ITSM). Within 18 months, business units demand Customer Service Management (CSM). By year three, HR wants Service Delivery (HRSD) and Finance wants GRC. Each conversation begins the same way: "We need this module. When can we have it? How much does it cost?"
The answer, in most cases, is wrong. Not intentionally. Procurement doesn't have a framework. IT doesn't understand the licensing architecture. Finance treats each module request as a standalone budget line. And ServiceNow's sales team has every incentive to sell on the spot, without surfacing the compliance risks, true-up mechanics, or negotiation leverage that dormant in your contract.
The result: enterprises spend 40-60% more on module expansion than they need to. They commit to editions that create compliance exposure. They trigger true-ups at LIST price for peak usage they didn't budget. They negotiate mid-contract, when they have zero leverage, instead of at renewal, when they control the conversation.
This guide presents the five-phase Module Expansion Framework: a systematic approach to evaluating, budgeting, negotiating, and governing new ServiceNow modules. The framework surfaces the edition architecture that underpins every licensing decision, explains where the compliance boundary sits, and shows you how to model the financial impact of expansion before you commit to it.
ServiceNow's Edition Architecture: A Framework for Understanding Tiers
ServiceNow's licensing model is built on editions, not users. You don't buy "ServiceNow licenses"—you buy access to a specific edition of a specific module, with that edition defining which features your fulfiller users can access.
Every ServiceNow module comes in three editions: Standard, Pro, and Enterprise. Some modules add Pro Plus and Enterprise Plus, which unlock advanced AI, analytics, and workflow automation. The confusion begins here: many enterprises mix editions without realizing it, creating dormant compliance risk.
Standard vs Pro vs Enterprise: The Critical Edition Boundary
The Pro/Enterprise boundary is the primary compliance risk in ServiceNow contracts. This is where most audits get triggered and where true-ups spike.
Standard is the entry tier: basic workflows, foundational reporting, no advanced analytics, no AI. Pro adds intelligent automation, advanced analytics, deeper customization, and process mining. Enterprise adds strategic reporting, advanced AI, API prioritization, and dedicated support tiers.
The risk emerges when you license Pro users but they access Enterprise features—for example, Advanced AI features in Now Assist that are restricted to Enterprise Plus. ServiceNow's audit mechanism counts actual feature usage, not the edition you paid for. If peak usage exceeds your contracted quantity, you owe true-up at LIST price, not your negotiated discount.
The edition boundary is enforceable per module. You can run ITSM Standard while HRSD runs Enterprise. But within a single module, mixing editions triggers compliance exposure. The secondary risk: your contract must explicitly define which edition each fulfiller user runs. If it doesn't, ServiceNow will argue you owe Enterprise pricing for all of them during a true-up.
Pro Plus and Enterprise Plus: The AI Premium
Now Assist AI is a premium add-on available only to Pro Plus and Enterprise Plus customers. It's not included in Standard, Pro, or Enterprise editions. It's purchased separately and priced per fulfiller user per month.
The cost impact is significant: Now Assist AI adds approximately 60% premium on top of the base Pro or Enterprise edition cost. For a 500-user Enterprise ITSM deployment, that's a six-figure add-on per year. Most enterprises discover this during contract review and never surface it as a decision point.
Pro Plus and Enterprise Plus also unlock advanced analytics, predictive intelligence, and automation features not available in the base tiers. They're worth the premium—but only if you've modeled the use case, assigned ownership, and built the business case beforehand. "We might use AI" is not a procurement decision.
When evaluating module expansion, clarify upfront whether you need Pro Plus or Enterprise Plus, or whether the base Pro/Enterprise edition suffices. This decision cascades into your negotiation strategy and your financial model.
The Module Landscape: Understanding What You Might Add
ServiceNow's module portfolio has nine core offerings. Each has its own pricing model, edition tiers, and compliance mechanics. Understanding the module landscape helps you prioritize expansion and model costs accurately.
ITSM Expansion: Adding Fulfillers and Upgrading Editions
IT Service Management (ITSM) is the foundation module. Most enterprises begin here with Standard or Pro edition. Expansion happens in two ways: adding fulfiller users or upgrading existing users to a higher edition.
Adding fulfiller users scales linearly: each new user costs roughly 60-75% of the prior negotiated rate (based on typical enterprise discounts). Upgrading existing Standard users to Pro might cost 40-50% more per user; upgrading Pro to Enterprise might cost 30-40% more.
The compliance risk in ITSM: true-up is based on peak usage, not average usage. If you contract for 200 fulfiller users but peak at 250 (say, during holiday support surge), you owe true-up for 50 users at LIST price, not your negotiated discount. This is where many enterprises get surprised. You must forecast peak load, not steady-state load, and contract accordingly.
ITSM also supports Service Delivery integration with HR (see below). If you have HR Service Delivery and ITSM, they share fulfiller user counts under some contract structures. Verify that your contract defines whether fulfillers are shared or segregated by module.
CSM: Customer Service Management Licensing Model
Customer Service Management (CSM) is the customer-facing service delivery platform. Like ITSM, it comes in Standard, Pro, and Enterprise editions with identical pricing tiers. The licensing model is also per fulfiller user.
CSM expansion is often triggered by organizational change: you acquire a customer success team, stand up a support center, or expand geographically. CSM's compliance mechanics are identical to ITSM: peak usage determines true-up exposure, contract clarity on edition boundaries is non-negotiable, and pre-negotiating expansion rights at renewal saves 25-40%.
One nuance: CSM licenses customer-facing agents and internal fulfillment. If your support team has both roles, your contract must segregate fulfiller counts by function to avoid disputes during true-up. Agents and fulfillment users are often priced differently.
HRSD: HR Service Delivery and the Fulfiller Count Trap
HR Service Delivery (HRSD) is ServiceNow's HR operations platform. It also uses fulfiller-based licensing with Standard, Pro, and Enterprise editions. The primary compliance trap in HRSD: fulfiller count is often underestimated.
HRSD fulfillers include HR agents, benefits specialists, recruiters, managers with approval workflows, and sometimes employee portal users depending on your contract scope. Many enterprises miscalculate fulfiller count because they only count HR employees, not downstream users who touch the system to submit requests or approvals.
The second HRSD trap: shared fulfiller licensing with ITSM. Some ServiceNow contracts define fulfillers at the organization level and allow sharing across modules. Others segregate fulfiller counts per module. This distinction matters enormously for true-up exposure. If your contract allows sharing and ITSM usage spiked 30% during a fiscal year, HRSD fulfiller availability shrinks accordingly—or true-up costs spike because you exceeded shared capacity. Verify this in your contract before expanding either module.
ITOM: Configuration Item Pricing (Not User Pricing)
IT Operations Management (ITOM), specifically Discovery, breaks the fulfiller-based pricing model. ITOM Discovery is priced per Managed Configuration Item (CI), not per user. This is critical because it inverts the business case entirely.
A typical ITOM Discovery deployment might scan 50,000 Configuration Items from your data center, cloud infrastructure, and applications. The cost is per CI. A 500-user IT operations team might assume "we have 500 users, it should cost roughly $X per user." Wrong. A single discovery scan of 50,000 CIs costs far more than a 500-user license—often 10-50x more depending on your configuration density.
When evaluating ITOM expansion, you must enumerate your actual CI count, not your user count. Run a discovery pilot to establish baseline CI inventory. Budget conservatively: CI counts typically grow 15-25% year-over-year as infrastructure complexity increases. Pre-negotiate CI growth caps at renewal to avoid true-ups on CI overflow.
App Engine: Platform Expansion and Studio Licensing
App Engine (with Now Studio) is ServiceNow's low-code application development platform. Unlike traditional modules, App Engine is often licensed by named developer or by deployment slot, not fulfiller count. Licensing models vary: some enterprises buy developer licenses; others buy deployment slots for applications built outside ServiceNow.
When evaluating App Engine expansion, clarify whether you're licensing developers or deployment capacity. Developer-based licensing scales linearly with your IT development team. Slot-based licensing is fixed-cost per application. Hybrid models also exist. Your negotiation strategy and cost model depend entirely on which licensing method you're pursuing.
Pre-negotiating module expansion rights at your ServiceNow renewal saves 25-40% versus mid-contract expansion.
Start with our 10-Step Renewal ToolkitThe Five-Phase Module Expansion Framework
The module expansion framework codifies the decision sequence from business case through governance. Each phase has a distinct output, approval gate, and accountability.
Phase 1: Entitlement Inventory
Before you can expand, you must know what you have. Entitlement inventory is a complete snapshot of your current ServiceNow licensing: every module, every edition tier, every fulfiller count, and every contract commitment.
Start with your contract. Extract the schedule of entitlements: modules, editions, fulfiller counts, any per-module caps, any shared fulfiller arrangements. Then run an actual usage report from ServiceNow's analytics—ideally over a 12-month period to capture seasonality and peak load.
Compare contracted entitlements to actual usage. Is peak usage within your contract limits? Where is usage trending? ITSM growing 3% annually or 15%? CSM new and spiking? HRSD stable?
This phase surfaces dormant compliance risks: if actual peak usage exceeds contracted quantities, you're already exposed to true-up. If you discover shared fulfiller arrangements that you didn't know about, you understand the constraint before you try to expand.
Entitlement inventory takes 4-8 weeks to complete depending on organizational size and contract complexity. It's tedious. It's also the most important phase of the framework.
Phase 2: Business Case and Cost Modelling
Once you know what you have, you can model what expansion costs. Cost modeling requires three data points: expected fulfiller count (or CI count for ITOM), expected edition tier, and peak load projection.
For a CSM expansion (200 new customer service agents), your cost model includes: 200 fulfiller users × pro edition rate × 12 months. But it also includes peak load: are those 200 agents all active simultaneously, or does customer demand peak at 240 during holiday season? Your contract must accommodate peak, so you budget for 240 even though average is 200.
Cost modeling also surfaces forced upgrades. If you expand ITSM and simultaneously want Now Assist AI, you must upgrade from Pro to Pro Plus (or Enterprise to Enterprise Plus). That decision cascades: 500 existing users upgrade to Pro Plus at 60% premium each. Suddenly a 200-user expansion has $400K of forced upgrade costs that weren't visible in the original ask.
Business case approval happens here. CFO needs to see: expansion cost, payoff period, forced upgrade costs, and true-up risk if peak usage deviates from forecast. If the business case doesn't justify the spend, you don't proceed. If it does, you move to negotiation strategy armed with real numbers.
Phase 3: Negotiation Strategy and Timing
Timing is leverage. ServiceNow's fiscal year ends December 31. Q4 (October-December) is the maximum leverage window for renewal and expansion negotiation. If you're expanding mid-contract (say, in June), you have no leverage and will pay full rates.
Negotiation strategy depends on contract status:
- At renewal (within 60 days of renewal date): Pre-negotiate expansion rights as part of the renewal. Typical discount: 40-60% off list for core ITSM, 60-80% off for newer modules like CSM or HRSD. Bundle expansion with renewal to maximize discount depth.
- Mid-contract (12+ months until renewal): Expect 10-30% discount off list rates. ServiceNow has zero urgency. You're competing against their Q-close targets and pipeline. Only negotiate mid-contract if business urgency justifies the premium cost.
- Q4 timing (October-December): If you have flexibility, negotiate in Q4 when ServiceNow's annual close cycle creates edge. Renewal discussions gain leverage; new module expansion can be bundled into closing targets.
The negotiation strategy also includes contract terms: define edition boundaries, peak load buffers, shared vs. segregated fulfiller counts, and true-up caps (if negotiable). These terms protect you downstream when usage deviates from forecast.
Phase 4: Contract Terms and Protections
The actual negotiation output is a contract amendment or renewal agreement that codifies the expansion. The critical terms:
- Edition clarity: Every module must explicitly state which edition each fulfiller runs. "ITSM Pro for IT service fulfillment, ITSM Enterprise for strategic reporting access" is clear. "ITSM Pro users" without role definition creates compliance exposure.
- Fulfiller count definition: Define who counts as a fulfiller. Does a part-time approver count? Does a vendor? Does a manager with workflow access count? Your contract must exclude ambiguity.
- Peak load buffer: Contract for peak usage, not average. If you expect 200 fulfillersand peak 240, contract for 240. If your forecast is wrong and peak hits 280, you owe true-up at LIST price on the 40-user overage. A conservative peak buffer (110-120% of expected average) protects you.
- True-up mechanics: Your contract should define how true-up is calculated, when it's measured (annual vs. per-quarter), and whether you get credit for forecasting conservatively. Some contracts cap true-up exposure; others don't.
- Shared fulfiller segregation: If ITSM and HRSD share fulfiller capacity, your contract must define the split. Without definition, true-up audits create disputes that favor ServiceNow.
Contract protection is unglamorous work. It's also where compliance risk gets locked in or locked out. Spend time here.
Phase 5: Governance and Compliance Monitoring
The framework doesn't end at contract signature. Governance and monitoring is continuous: tracking actual usage against contracted capacity, monitoring for new use cases that might trigger additional expansion, and planning ahead for the next renewal.
Set up a quarterly usage review: pull actual fulfiller counts by module and edition, compare to contract, identify trend. If ITSM is growing 20% annually but your contract projects 5%, you need to recognize the delta and plan expansion 6-9 months before peak usage hits.
Establish an expansion approval gate: any new module request goes through entitlement → business case → negotiation → contract phases before signature. This prevents ad-hoc purchases at inflated mid-contract rates.
Document all expansion agreements. Many enterprises sign amendments, lose the email, and 18 months later forget what they contracted. A central expansion register (spreadsheet, SharePoint, whatever) prevents disputes during true-up audit.
The Edition Boundary Compliance Risk: Where Most Enterprises Get Caught
The Pro/Enterprise boundary is the most litigated compliance line in ServiceNow true-ups. Here's why: the feature gap between editions is subtle and blurry. Pro users often accidentally access Enterprise features. ServiceNow's audit mechanism flags this as out-of-compliance.
The mechanical question: does Now Assist AI count as an Enterprise-only feature, or is it available to Pro users? The answer is Pro Plus or Enterprise Plus only. If a Pro fulfiller tries to use Now Assist, they'll hit a permission block—or they'll use it through a workaround (sometimes possible if your admin grants access) and trigger an audit exception.
The compliance exposure compounds: if 10 Pro users "accidentally" access Enterprise features and peak actual usage rises to 210 (vs. contracted 200), you owe true-up not only on the 10 unauthorized users but potentially on all 210 if ServiceNow argues the entire cohort was running Enterprise-level features.
Protection mechanisms:
- Edition-specific role assignment: Assign roles by fulfiller and explicitly tie roles to contracted editions. Pro roles get Pro UI; Enterprise roles get Enterprise UI. Never assign roles with implicit edition crossing.
- Admin audit trail: Document who has access to which features and at which edition level. ServiceNow provides audit reports; pull them quarterly and reconcile to contract.
- Feature gating: Some features (like Now Assist AI) can be administratively restricted to specific editions. Enable those controls and verify they're working as expected.
- Contract clarity: Your contract should define the edition boundary explicitly and include a remediation clause: if you accidentally run users at higher editions, you have 30-90 days to remediate (downgrade to contracted edition) without true-up penalty. Without this language, ServiceNow will argue you owe retroactive true-up.
Now Assist AI: The Hidden Cost of Module Expansion
Now Assist is ServiceNow's native AI copilot. It's available only to Pro Plus and Enterprise Plus customers. It's priced separately: per fulfiller user per month, roughly 60% premium on top of base Pro or Enterprise rates.
For a 1,000-user Pro ITSM environment, Now Assist AI costs roughly $720K annually (1,000 users × $60/month estimate × 12 months). That's a massive add-on that most enterprises don't budget for when evaluating module expansion.
The hidden cost emerges during negotiation: if you want Now Assist, you must upgrade all affected users to Pro Plus or Enterprise Plus. You can't run Pro + Now Assist as a separate tier. The entire cohort must upgrade. For a 1,000-user Pro deployment expanding to include Now Assist, that's 1,000 base users × 60% premium = $360K+ upgrade cost plus the Now Assist add-on itself.
When evaluating whether to expand and add AI:
- Quantify the use case: Will agents actually use Now Assist daily? Weekly? What's the expected productivity uplift? Cost-justify the $720K investment with concrete metrics, not aspirations.
- Pilot with premium licensing: If you're unsure, negotiate Now Assist for a subset cohort (say, 100 super-users in your flagship location). Measure adoption, satisfaction, and cost-per-transaction. Scale only if the metrics justify it.
- Bundle with renewal: If you're expanding at renewal, negotiate both base module expansion and Now Assist as part of the same package. Bundling usually yields better pricing on both elements.
Now Assist is valuable. But "AI" as a justification without business case is the most common expansion mistake we see. Don't let it happen in your organization.
True-Up Mechanics: Why Peak Usage Destroys Mid-Year Savings
True-up is calculated on peak usage, not average usage. This is the single most misunderstood element of ServiceNow licensing. It's also where the biggest financial surprises emerge.
Here's the mechanic: you contract for 200 ITSM fulfiller users. Your average load is 190. But during December (holidays), peak load hits 240. Under true-up, you owe payment for 240 users, even though your contract specified 200.
The true-up is calculated at LIST price, not your negotiated discount. If your negotiated rate was $5,000 per user annually with a 50% discount ($2,500 actual), true-up on 40 overage users is 40 × $5,000 = $200K, not 40 × $2,500 = $100K.
Many enterprises budget conservatively for expansion (say, expecting 5% growth) only to encounter true-up bills for 20% overage. The financial surprise is severe.
Protection mechanisms:
- Conservative peak forecasting: Forecast peak usage, not average. If you expect 200 average and historical seasonality shows 20% spikes, contract for 240. Better to have 40 unutilized licenses than to owe true-up at LIST price.
- True-up cap negotiation: Some contracts cap true-up exposure: you owe true-up only up to 110% of contracted capacity, or maximum $500K per year. Without a cap, true-up is unlimited. Negotiate a cap if you can; it transforms unlimited risk into bounded risk.
- Quarterly monitoring: Pull actual usage reports quarterly. If Q1 and Q2 show 30% usage growth, you know Q3 or Q4 will likely spike. Proactively expand capacity in Q2 so you don't get surprised by Q4 true-up.
- Shared fulfiller transparency: If ITSM and HRSD share capacity, track combined fulfiller usage, not module-level usage. Your true-up exposure is at the shared pool level. Combined visibility prevents surprises.
ITOM Discovery Pricing: The CI Trap
ITOM Discovery is priced per Configuration Item, not per user. This inverts the traditional fulfiller-based model and creates a unique compliance trap.
A typical conversation: "We want to expand ITOM Discovery to scan our AWS cloud infrastructure. We have 500 cloud engineers. What does that cost?" The answer sounds like: "ITOM Discovery isn't priced per user. It's priced per Configuration Item. You need to enumerate your CIs first."
The customer then runs a discovery scan and discovers 50,000 CIs: EC2 instances, RDS databases, load balancers, subnets, security groups, auto-scaling groups, and more. The cost is per CI: 50,000 CIs × (per-CI rate) = $X per month. That X is often 10-50x higher than "500 engineers."
The true-up trap in ITOM: your CI count grows automatically as infrastructure scales. If you contract for 50,000 CIs and your cloud footprint grows 20% (to 60,000 CIs), you owe true-up on the 10,000 new CIs. Most enterprises don't see this coming.
When expanding ITOM Discovery:
- Enumerate your baseline CI count: Run a discovery scan in your current environments (on-premises, cloud, SaaS) and count actual CIs. Don't estimate; count.
- Project CI growth: Historical infrastructure growth rates typically run 15-25% annually. If you're growing 20%, contract CI capacity at 120% of current count to absorb that growth without true-up.
- Negotiate CI growth caps: Some ServiceNow contracts allow you to pre-negotiate the price of CI growth. Example: "First 55,000 CIs at negotiated rate; any CIs above 55,000 up to 60,000 at +10% markup; any CIs above 60,000 at +20% markup." This caps your true-up exposure.
- Segregate environments: If you're scanning across multiple environments (data center + cloud + SaaS), understand which environments are in-scope and which aren't. Some contracts exclude certain environments to reduce CI count.
Negotiating Module Expansion at Renewal vs Mid-Contract
The timing of expansion relative to your contract renewal is the single most important lever for controlling expansion cost. The difference between renewal and mid-contract expansion can be 40-60% of total cost.
At renewal: you're negotiating the entire contract: module mix, edition tiers, fulfiller counts, true-up mechanics, everything. Expansion is one element of that larger negotiation. ServiceNow is motivated to close the full year's contract in one deal. You have leverage to bundle expansion with renewal and maximize discount depth.
Typical at-renewal discount: 40-60% off list for core modules (ITSM, HRSD), 60-80% off for newer modules or add-ons. Why the gap? Core modules have mature competition (others offer ITSM-like capabilities); newer modules (App Engine, CSM) have less direct competition, so ServiceNow can hold higher list prices and still offer larger discounts.
Mid-contract: you're adding incremental capacity to an existing agreement. ServiceNow has no urgency. Your business need (new team, acquisition, organizational change) is ServiceNow's opportunity. Expect 10-30% discount off list. Some deals get worse terms: flat list price or minor single-digit discounts.
The financial gap is severe. A 200-user CSM Pro expansion at renewal costs roughly $400K (200 users × $5,000 list × 50% discount). The same expansion mid-contract costs $800K (200 users × $5,000 list × 20% discount). The difference is entirely driven by timing and negotiation leverage.
Strategic recommendations:
- Plan expansion for renewal: If you're planning CSM expansion for Q2 but your renewal is in Q4, consider deferring expansion to Q4 to negotiate at renewal. The $400K savings justifies the 6-month delay.
- Pre-negotiate expansion windows at renewal: Instead of deferring expansion, ask ServiceNow to define expansion pricing windows in your renewal contract. Example: "If we expand HRSD by December 31, we get the renewal pricing; if we expand after that, we pay mid-contract rates." This gives you a runway to expand at favorable rates without waiting for the next renewal.
- Understand your renewal date: Know when your ServiceNow contract renews. Start expansion planning 6 months before renewal. If you're 12 months away and need expansion urgently, expand mid-contract and plan the expansion window negotiation for your next renewal cycle.
- Bundle add-ons with renewal: If you're adding Now Assist AI, additional ITSM fulfillers, and a new CSM module all at the same time, bundle them into a single renewal negotiation instead of negotiating separately. Bundling improves your total discount.
Maximize your ServiceNow negotiation leverage with our proven strategies.
Learn our 10-step renewal methodologyEight Priority Recommendations
- Establish entitlement inventory now. Before you expand, know what you have. Pull your contract, run usage reports, and identify dormant compliance risks or unutilized capacity that can absorb demand before expansion is needed.
- Define edition boundaries explicitly in every contract amendment. Pro vs. Enterprise isn't a conversation; it's a contract term. Your renewal or expansion amendment must define which fulfiller runs which edition. Ambiguity creates true-up exposure.
- Contract for peak usage, not average usage. Peak load during holidays, fiscal close, or crisis is real. Build a 10-20% buffer into your contracted capacity. It costs less than true-up at LIST price.
- Defer expansion to renewal if financially viable. If you can absorb expansion demand for 6-9 months until your renewal, do so. The 40-60% discount savings at renewal vs. mid-contract expansion often justifies the delay and operational workarounds.
- Pre-negotiate expansion windows at renewal. Define pricing for post-renewal expansion (say, within 12 months) in your renewal agreement. Lock in renewal-tier pricing for planned expansion and eliminate mid-contract premium.
- Quantify Now Assist AI business case before licensing. Don't let "AI" be a justification without metrics. Pilot with a subset cohort, measure adoption and productivity impact, and scale only if the ROI is concrete.
- Enumerate CI count and project growth for ITOM Discovery. Don't estimate CI count; measure it. Project 15-25% annual growth and contract accordingly to avoid true-up on organic infrastructure expansion.
- Establish quarterly usage governance and monitoring. Pull actual usage quarterly, compare to contract, and identify trends. Early detection of demand growth gives you 6-9 months to plan expansion proactively instead of reactively.
Conclusion
Module expansion is inevitable. Every scaling enterprise adds CSM, HRSD, or specialized modules as business needs evolve. The expansion decision doesn't need to be expensive or risky. It needs to be systematic.
The five-phase Module Expansion Framework—entitlement inventory, business case, negotiation strategy, contract protection, and governance—codifies a repeatable process that eliminates guesswork, surfaces hidden costs, and maximizes your negotiation leverage.
The critical insights:
- Edition boundaries (Pro vs. Enterprise) are the primary compliance risk. Define them explicitly in contracts.
- True-up is based on peak usage, not average. Contract conservatively and budget the 10-20% buffer.
- Pre-negotiating expansion rights at renewal saves 25-40% vs. mid-contract expansion.
- Now Assist AI is a 60% premium add-on. Quantify ROI before licensing.
- ITOM Discovery is priced per CI, not per user. Measure your CI baseline and project growth.
If you're planning module expansion in the next 6-18 months, start with entitlement inventory and business case modeling. Understand what you have, what you need, and what it actually costs. Then negotiate from a position of clarity and leverage, not from surprise and urgency.