Fifty-two simultaneous users did not answer a named-user proposal

## Understand the measure before using the difference

The chart seemed to offer an immediate negotiating advantage. A software proposal covered 280 named users, while the highest observed number using the service at the same time was fifty-two. The gap was large enough to invite a simple conclusion: buy only enough for the peak. That conclusion moved too quickly. A count of people entitled to use a service and a count of simultaneous activity can describe different aspects of the same population. Their difference does not, by itself, establish what the customer is permitted to purchase or how access may be shared.

The proposal at Vornqemi was priced at ₹1.8 crore annually on a named-user basis. We needed procurement, legal and the supplier to clarify its actual terms. The technology team's utilisation evidence was valuable, but it was not a substitute for that examination. I did not want an executive discussion to turn a usage statistic into permission that the company had not obtained. Nor did I want the commercial basis to prevent a serious review of whether all 280 people needed the proposed service tier. Those were two different questions, and both deserved an answer.

Procurement reasonably wanted to challenge an apparently broad requirement. Finance wanted evidence that the company was not paying for access simply because it had been requested in a large initial group. The operational sponsor worried that a tighter allocation would leave people unable to perform occasional but important work. These positions were not signs that one function understood the problem and the others did not. They represented different consequences of the purchasing decision. My role was to make the measures and needs clear enough for those consequences to be considered together.

I would be wary of any general rule that occasional use means an entitlement is unnecessary. A person may need a service infrequently but have a legitimate task that cannot be completed through another route. Conversely, being included in a project or department does not automatically establish a need for the full paid tier. The useful question is what work the person must perform, when they must perform it and what approved options support it. That is a more demanding account than either accepting the original headcount or replacing it with a peak from a utilisation graph.

## Question the requirement without inventing an entitlement

We spent ₹46 lakh on the assessment. It examined the tasks associated with the proposed users and the alternatives actually available under the arrangement being discussed. The resulting requirement identified 213 people needing the paid tier and sixty-seven whose work could follow another approved route. Those groups accounted for all 280 originally proposed users. The review did not establish that fifty-two licences were sufficient. It established a different, more specific requirement for the commercial team to take back into discussion with the supplier.

The other route needed to be understood on its own terms. It could not be described as full access delivered informally through someone else's account. Nor should a person be moved to it merely to make the paid-user number look smaller if the route did not support their actual work. Appropriate owners had to explain what it permitted and where its limitations mattered. The CIO's responsibility included making those limitations visible, while commercial and legal colleagues retained the interpretation and agreement of the actual entitlement. A technically possible workaround was not automatically an authorised service design.

The assessment also had to recognise change over time. A requirement based on today's tasks may need revision when responsibilities or the service itself change. I wanted an accountable way to review that change rather than an assumption that the initial allocation would remain correct indefinitely. This did not require predicting every future request before making a purchase. It required understanding who would examine a new need and how the commercial and technical account would be kept consistent. Otherwise an initially careful allocation could gradually become another unexplained group of names.

There was an inconvenience in doing this work before claiming a result. The original graph offered an immediate story about apparent waste. A role and task review took longer and could produce a less dramatic answer. I accepted that delay because the company needed a service it could use appropriately, not merely a favourable number in a negotiation presentation. The cost of the assessment remained visible. It might be justified by a better purchasing decision, but it did not disappear because the final requirement was narrower than the initial request.

## Keep the negotiation separate from a savings announcement

The ₹1.8 crore figure was the original annual quote. It was not expenditure already incurred, and reducing the proposed paid population did not create a realised saving by arithmetic alone. The actual commercial terms, service scope and later spending would determine the financial account. I did not ask the team to multiply the difference in user counts by an assumed unit price and present the result as cash released. A supplier may price the arrangement through several conditions, and those conditions require review rather than inference from a single headline amount.

Finance should be able to distinguish the original proposal, the revised requirement, the agreed commitment and the eventual expense. Each is useful at a different stage. Confusing them can make a programme appear to have delivered a financial result before the company has even agreed what it will buy. The same discipline applies to implementation and support costs. A narrower licence requirement may still involve training, administration or another service route. Those consequences belong in the decision rather than being left outside the account because they make the savings narrative less simple.

This is not an argument for accepting supplier terms without challenge. Understanding the proposed entitlement makes the challenge more precise. The customer can explain the work it needs, question whether the offered structure is appropriate and negotiate alternatives through the proper process. The supplier can respond to a defined requirement rather than a demand based on a statistic measuring something else. A clearer discussion may still end without agreement. It is more useful than a superficially strong negotiating position that depends on a permission neither party has actually accepted.

For a board, I would frame the case around the quality of the purchasing account. Does management understand what the proposal counts? Has it examined the business need behind the requested population? Are alternatives authorised and usable? Which financial figures are proposals, commitments or observed expenditure? Directors do not need to allocate individual software access to ask those questions. They need confidence that management can distinguish the technology evidence from the commercial conclusion and show where further work or cost remains before a claimed benefit becomes real.

My practical lesson is to resist the attraction of a large difference until I understand its units. The gap between 280 named people and fifty-two simultaneous users was worth investigating. It was not the answer to the purchasing decision. The review produced a requirement of 213 paid-tier users and sixty-seven people on another approved route, with the assessment cost retained and the commercial outcome still to be agreed. That was a less immediate story than buying for the peak. It was a decision the business could explain without asking a chart to create an entitlement it did not contain.