Common ServiceNow Software License Optimization Mistakes and How to Avoid Them

Software license optimization mistakes come from how licenses are counted, bought and retired, not from the software itself. This page walks through seven common errors, the symptom each one produces, the root cause behind it and the fix that stops it recurring.

Mistake 1: Licensing Based on Worst-Case Peak Usage

Symptom: You buy enough licenses for the peak number of concurrent users, but actual average usage is much lower. Most of the time, you are paying for licenses you do not use. Root cause: peak usage happened once during a crunch period, and licensing was based on that peak rather than on typical usage. Fix: analyze usage patterns over months, not days. Calculate 95th percentile usage (meaning during occasional peak periods usage exceeds this level). License to that level instead of peak. Understand that occasional peaks do not justify full license purchases. Prevention: collect and analyze usage data before making licensing decisions. Track usage over time, not just snapshots.

Mistake 2: Not Tracking Installed Licenses Versus Deployed Licenses

Symptom: Procurement says you bought 500 licenses but Software License Optimization says only 200 are deployed. You are either overpaying for licenses you do not use, or the deployment process is broken. Root cause: installation and deployment are different. A license can be installed but never used. Or a license can be used without being properly installed (bootlegged or pirated). Fix: reconcile installed and deployed licenses. Identify licenses that are installed but not used and see if they can be repurposed or returned. Identify deployed licenses that are not installed and see if they are compliant. Prevention: make deployment tracking part of software provisioning. When software is installed, record it in Software License Optimization.

Mistake 3: Ignoring Unused Software Titles

Symptom: You maintain licenses for software nobody uses anymore. Money is wasted on maintenance and licensing for deprecated software. Root cause: software was necessary once but has been replaced. The old licenses were not decommissioned. Fix: audit deployed software. Identify titles with zero usage over a period you set. Confirm they are truly not needed, then cancel the licenses. Prevention: tie software retirement to license management. When IT retires software, Software License Optimization should be notified so licenses can be cancelled.

Mistake 4: Over-Buying When Negotiating Discounts

Symptom: Vendor offers a discount if you buy more licenses. You buy the bulk quantity to get the discount, then later discover you do not need all of them. Root cause: discount incentives can override good judgment about actual need. Fix: analyze total cost of ownership over the contract term. A discount that requires buying significantly more licenses might not be a good deal. Pass on discounts that require buying more than you need. Prevention: set spending authority rules: bulk license purchases require approval from someone who understands actual usage and future plans. Do not let procurement departments buy extra licenses just to hit discount thresholds.

Mistake 5: Not Automating License Compliance Checking

Symptom: Audits discover compliance violations (running more copies than licensed) only after vendors notice and send bills for true-ups. Root cause: license compliance was never monitored continuously. Violations accumulated without detection. Fix: set up automated compliance checks that compare deployed licenses to purchased licenses. Alert when usage approaches limits. Prevention: enable continuous monitoring and alerting. Check license compliance at least monthly. When alerts trigger, investigate immediately rather than waiting for an audit.

Mistake 6: Consolidating Vendors Without Consolidating Licenses

Symptom: You consolidate on a single enterprise platform (like ServiceNow) but keep licensing from multiple vendors because switching would be disruptive. Over time, costs increase because you are paying overlapping vendor fees. Root cause: fear of disruption prevented migration even when it would be cost-effective long-term. Fix: calculate total cost of ownership including licensing cost. If consolidation saves more in licensing than the migration effort costs, do it. Break the project into phases to spread out disruption. Prevention: when evaluating platform consolidation, include licensing costs in the evaluation. Calculate savings over multi-year contracts, not just implementation costs.

Mistake 7: Not Using Open Source or Free Alternatives

Symptom: You pay for software for use cases where open-source or free alternatives would work. Root cause: nobody investigated alternatives because the original vendor was already chosen. Fix: audit your software portfolio. For each title, investigate whether free or open-source alternatives exist. Evaluate whether the alternative meets your needs. For cases where alternatives are viable, migrate if cost savings justify the effort. Prevention: include alternative evaluation in software procurement decisions. Do not automatically re-purchase the same vendor when contracts expire.

Prevention Summary

Optimize software licensing continuously, not just at renewal time. Track usage to drive licensing decisions. Retire software and licenses promptly when no longer needed. Consolidate vendors where it is cost-effective. Evaluate alternatives to expensive tools. Use continuous compliance monitoring to catch violations early.

Counting the unit the contract actually uses

Many compliance scares start with a counting mismatch rather than with any software being misused. A license sold per user is counted once for each person, however many devices that person owns. A license sold per device is counted once for each machine, however many people share it. If the optimization model counts devices for a per-user product, every user with a laptop and a desktop appears to be two users, and the apparent over-deployment is an artifact of the method. The fix is to write the counting unit into the product record before any number is compared with it.

Splitting one product across two records

When an editing change, a version upgrade or a second purchase creates a new product record while the old one stays open, usage gets divided between them. Each record then looks under-used, and a reduction is proposed on a license that is in fact fully consumed. The signal is a pair of records with similar names, one of them carrying almost no use and the other carrying more than its entitlement. Merge the records only after confirming that both are covered by the same agreement, because merging across agreements hides the real position.

Trusting a vendor report without a second source

Vendor usage reports are useful and often authoritative for the vendor’s own metric. They are not automatically a fair picture of the estate. A report can omit users who sign in through a reseller account, count a service account as a person, or lag the internal record by a full billing cycle. Where the internal and vendor figures differ, the difference is the investigation. Neither figure should be adopted as correct until the reason for the gap is written down.

Reading a true-up as a failure

When an audit or a vendor count finds more use than was licensed, the instinct is to treat the result as a failure to be hidden or resolved fast. That instinct often produces the worst outcome. Under time pressure, teams buy the shortfall at list price, accept a long-term commitment they did not need, or dispute a count they had not checked. A true-up is a commercial settlement of a measured difference. Check the count first, then the contract’s terms for settling it, and only then decide whether a purchase, a re-platform or a documented exception is the cheapest honest answer.

Reducing seats in the middle of a move

A team that is migrating a product to a new platform may still see idle seats on the old one and decide to cut them. The cut is often reasonable on its own and damaging in combination with the move. The destination must hold its entitlements before cutover, and any user who has not yet moved still needs a seat. Hold reductions on products in an active migration until the cutover has passed its acceptance point.

A recovery sequence when a mistake has already been made

1. Stop further changes to the affected products until the cause is known. A second reduction made on top of a miscount compounds the error.
2. Record the current entitlements, counts and any changes already made, with dates. This is the baseline the rest of the work is measured against.
3. Identify which of the patterns above explains the difference, using the table below.
4. Correct the record, not just the figure. A corrected report with an unchanged metric will produce the same error next cycle.
5. Brief the decision owner with the revised position and the revised saving. A saving that was never real should be withdrawn openly, since finance will otherwise plan around it.

Can a mistake be fixed at the next renewal?

Sometimes, but a renewal is a poor moment to discover a counting error, because the commitment is already on the table. Find the metric problem before the renewal conversation starts, so the negotiation is based on a corrected count.

What is the earliest sign that the team trusts one source too much?

When a figure is quoted without its source attached. If the number cannot be traced to a named report, a dated export and a metric, it has not been checked.

Who should review counts before they reach finance?

Someone who did not build the count. A reviewer who has seen the agreement is often the strongest check, because many errors sit between the contract and the data, not inside either one.

Is a true-up always avoidable?

No. Some true-ups follow from real growth in use that nobody planned for. The aim is to make the settlement a decision rather than a surprise, and to know the cost before the count is confirmed.

A count that has already gone wrong is easier to correct when its evidence sits in one place.

Related guides: ServiceNow Software License Optimization Best Practices and ServiceNow CMDB Ownership: Assign Accountability by Data.

Optimization and Compliance Answer Different Questions in a Set Order

License optimization asks whether you pay for the software you use. License compliance asks whether you use the software you are entitled to. Both questions need the same two inputs, the entitlement and the usage, but they lead to different actions. In practice, settle compliance first so that every optimization decision rests on a count you can defend.

A compliance finding can force a purchase, while an optimization finding usually leads to a reduction. That asymmetry is why the inputs for compliance need settling before any reduction is proposed.

The order matters because a reduction built on a wrong count can leave the estate short once the vendor counts it. Optimization is only as good as the entitlement baseline underneath it. The practical order runs as follows:

1. Agree the entitlement baseline for each product: the contracted counts, the counting unit and the agreement that covers it.
2. Reconcile usage against that baseline across the full billing cycle, and write down every gap with its cause.
3. Close the compliance gaps first, either by buying the shortfall or by recording a documented exception.
4. Only then look for idle entitlement, and propose reductions at renewal where the contract allows that.
5. Repeat the reconciliation before each renewal, because a count that was right last quarter can drift by the next one.

Usage data is where this sequence most often stalls. Decide how the usage feed reaches the optimization model before the first reconciliation, because the collection method decides how far the result can be trusted. The options are set out in our license optimization integration patterns.

If this reconciliation has to run every cycle, the next step is the software asset management professional guides.