Vendor Responsiveness Compounds Enterprise Trust
University College London’s CMDB discovery and service mapping evaluation reveals how enterprise trust is built layer by layer
In June 2024, Bain & Company surveyed software customers and practitioners, asking each which customer success activities mattered most. The results, published in the Bain Technology Report that September, showed a split: buyers ranked technical implementation and deployment as their top priority. The practitioners serving them ranked it sixth. The authors put it plainly: “It turns out a huge disconnect exists between how customers want to be served and what vendors think they need.”
In 2025, Info-Tech Research Group’s Software Buyer Insights report found the same fault line from a different angle. Software satisfaction had shifted from feature comparison to relationship management. Buyers now switch vendors over relationship breakdowns more often than over missing features.
By February 2026, Info-Tech’s senior research analyst Emily Wright named the pattern directly, in the firm’s Support Superstars report: “Feature comparisons dominate software selection, but long-term outcomes are shaped by vendor support.”
This is exactly what we experienced with University College London (UCL) recently. Even after a thorough POC, new requirements (including a not-so-trivial one from the IT security team) surfaced after the sale closed. These previously unscoped technical requirements created critical blockers to the implementation timeline and risked ultimate success of the project.
Three independent sources, two years apart, point to the same pattern. A feature set closes the sale. Vendor responsiveness after signature earns the trust. UCL’s evaluation shows both halves of that pattern in one place: what got scored before the purchase, and what got tested once the contract was signed.
A University Built on a Century of Nobel Laureates, Running on Spreadsheets
UCL has produced 33 Nobel laureates across its history, sits ninth in the QS World University Rankings 2026, and holds membership in the Russell Group. Founded in 1826 as London’s first university, it now supports more than 51,000 students from 150-plus nationalities and over 18,000 staff across 11 faculties, on a total income of £2.2 billion in 2024/25.
The IT estate behind that scale is massive, containing two large data centers, 5,000 virtual machines (VMs) and containers, Amazon Web Services (AWS) and Microsoft Azure running in parallel, 500 services, 1,000 applications, 1,200 network components, 180 departments, and 45,000 wireless clients connecting every day.
Against that estate, the actual state of configuration management looked like this: services were manually defined in their Xurrent ITSM with no links to the infrastructure configuration items (CIs) underneath them. Asset management ran on no standardized process. Spreadsheets carried what a system should have carried. Institutional knowledge, not documented data, held the estate together. Xurrent itself had no native discovery capability to close that gap.
A university old enough to have shaped two centuries of physics, medicine, and economics was running its infrastructure map the way a much smaller organization might, by memory and manual updates. That was the condition UCL’s evaluation had to solve for.
What UCL Scored Vendors On
UCL evaluated three options against three requirements: automated CI discovery, dependency mapping, and Xurrent ITSM integration. Lansweeper, Virima, and an internal tooling build were assessed side by side. Only Virima met all three requirements.
Paula Kirby, UCL’s Director of Service Management, described what actually decided the outcome: “It was the dependency mapping we had to prove: that it gave the right value before going ahead with purchase. So we spent a long time on it.”
Dependency mapping wasn’t one requirement weighted equally among three. It was the requirement the evaluation itself had to prove out: the piece that determined whether the entire selection process converted into a purchase.
What the Deal Actually Closed On
The purchase decision came down to a single, narrow, provable claim: could the dependency map be trusted against a live, changing estate. Not a comparison of feature lists across three vendors. Not a broad claim of platform superiority. One scored capability, validated to the buyer’s satisfaction, closed the deal.
That distinction matters for what comes next. A capability proven during evaluation is a capability proven against the scope the evaluation defined. It says nothing yet about what happens when the estate produces a requirement nobody wrote into the RFQ.
Discover how Virima builds trusted runtime truth across your live IT estate
What Nobody Scored, and What Happened After Signing
After the sale closed, new requirements surfaced that the original RFQ had never scoped: new security requirements for scanning, Oracle database (DB) discovery, virtual machine (VM) tagging, and a third-party integration to Xurrent that wasn’t yet fully mature.
Paula Kirby described how that gap got closed: “Virima was very responsive to enhancement requests: Oracle DB discovery, security-compliant scanning, and the Xurrent connector were all iterated collaboratively.”
The payoff from that iteration showed up in what Paula described as the moment the system proved itself operationally: “We ran the maps and that’s where we just saw those dependencies come to life. This is what we wanted. It’s come together. Service-to-service view in Xurrent, and service-to-component view in both Xurrent and Virima. That’s the source of truth.”
Mandy Silk, UCL’s Service Management Principal, described what that source of truth changed operationally. On incident management: “Our incident process is reactive. Say one of our databases is down; there are a number of different applications using that database that we tend to find out about only when issues arise. We get everyone on a call and start looking.” Against that starting point, she described the shift: “What Virima gives us is the ability to be much more focused in our efforts, not only when we have a reactive incident, but proactively too. We’ll be able to identify the potential impact before it escalates.”
On change management, Mandy Silk drew the same line between manual judgment and mapped fact: “If you don’t know the potential impact of a change to a CI, you simply cannot do a proper risk assessment. Right now, all those assessments are very manual, based on our knowledge pool. With Virima, we’ll be able to see the potential impact of a change before approving it. That’s where the real power comes from.”
The Test That Doesn’t End at Signature
Mandy Silk’s advice to other IT leaders evaluating a CMDB reinforces the discipline UCL applied before signing: “If you’re going to do it, do it properly. If we had gone any faster, we would have gone to production without the right discovery or integration in place, and we just wouldn’t have got the value.”
Paula Kirby’s advice points to the discipline that matters after signing: “We spend a lot of time talking about the operational impact of the CMDB. But what I’d focus on is how do you embed the CMDB operationally? How do you keep it green? How do you get people to use it day-to-day? It’s not just about getting the data right. It’s about getting people to rely on it.”
Both statements describe the same underlying pattern the Bain and Info-Tech research independently identified: the evaluation that closes a deal and the relationship that sustains it are two different tests. UCL’s own recommendation reflects having passed both. Mandy Silk: “The teams at Virima have actually made it simple for us … we are so happy and we’ve had great support throughout. We see Virima as the final piece of our journey, and we’re very excited about what’s ahead.” Paula Kirby: “Yes, we would start this journey all over again, and we would absolutely recommend Virima.”
For enterprise IT leaders evaluating similar technologies, an RFI or request for proposal (RFP) establishes what a vendor claims on paper. A POC tests whether those claims hold against a live estate. In many cases, it reveals something beyond that: whether a vendor delivers on enhancement requests during the evaluation itself, before any contract is signed. That kind of responsiveness during a POC is a preview of the responsiveness a buyer will depend on once the deal closes, a pattern worth watching for, alongside the requirements actually being scored.
See how Virima performs against your live estate — schedule a demo
