Blog

25 Questions to Ask an ITSM Vendor That Go Beyond the Demo

July 23, 2026
Jim Hirschauer
8 Mins
Gray upward-pointing arrow icon.
Click To Explore

Table of contents

Downward-pointing chevron dropdown arrow icon in black.

A customer once asked us to build something highly specific. A one-off feature, custom to their business, that would never apply to anyone else. We said no.

They left for a vendor who said yes.

The demo they got was great. The system that got built was so heavily customized around their unique request that when it came time to move from testing into production, the data transition broke. The whole thing fell apart. They lost confidence in that vendor and came back to Xurrent, where they remain a customer today.

This is not a rare story. It is close to a composite of what we hear, again and again, from organizations that have switched ITSM platforms more than once. The grass is not always greener on the other side, and the vendor willing to say no to over-customization might be protecting you from exactly this outcome.

The demo shows you the software. It doesn't show you the partnership.

Buying ITSM software is not really a purchase. It's the start of a multi-year relationship, and most buyers evaluate it like a transaction instead. Feature comparisons dominate the evaluation process because features are easy to see and score. What's much harder to see in a 45-minute demo is what happens after the contract is signed: how support actually responds at 2 a.m., whether the roadmap moves when you ask it to, what an upgrade feels like eighteen months in.

Those are the things that show up later, usually at the worst possible time. Here are 25 questions worth asking before they do.

Product philosophy & customization boundaries

Every vendor will show you flexibility in a demo. Fewer will tell you where their flexibility ends, and that boundary matters more than the flexibility itself.


    • When has your product team said no to a customization request, and why?
    • What happens to a heavily customized instance when it's time to upgrade?
  • Release cadence & upgrade experience

    Xurrent ships product updates on a weekly cadence, with changes released to a QA environment first so customers can review them and shape what ships before it reaches production. That is a meaningfully different experience from a vendor that upgrades once or twice a year.

    • How often do you release updates, and does upgrading require downtime or a change window?
    • Do customers see and test changes before they go live, or only after?

    Customer support model

    • Is support delivered by the vendor directly, or handed off to a partner or outsourced team once the contract is signed?
    • What does your escalation path look like for a critical issue at 2 a.m.?

    Customer success / relationship ownership

    • Will I have a named point of contact after go-live, or does my account get routed to a general queue?
    • How do you measure whether my organization is actually succeeding with your platform, beyond renewal?

    Roadmap influence

    • If my team requests a change, what's the realistic path from request to shipped feature, and who decides?
    • Can you show me something that shipped in the last year because a customer asked for it?

    Pricing & packaging philosophy

    Xurrent doesn't publish fixed pricing tiers because plans are built around each organization's needs, and the company has said its licensing is designed to avoid surprise overage penalties if a team temporarily exceeds its user count. That's a useful contrast to ask about directly.

    • What happens if we temporarily exceed our licensed user count?
    • Are there hidden costs for support tiers, API access, or add-on modules I should know about now?

    Community & peer network

    • Is there an active user community where customers exchange ideas directly, and can I talk to someone in it before I sign?
    • How does the vendor use community feedback to influence what gets built? Can you show me an example?

    Target market focus

    A platform built primarily for 50,000-seat global enterprises tends to carry assumptions that don't fit a 1,000-person IT team, and vice versa. Xurrent has been recognized on industry lists specifically for how its roadmap is built around midsize organizational needs, which is a different design center than platforms built for the largest enterprises first.

    • Who is your platform actually designed for, and how does that show up in the product?
    • Can you introduce me to a customer close to my size and industry?

    Vendor financial stability / staying power

    • How long has the company been profitable or well-funded, and what's the ownership structure?
    • What happens to my data and my instance if the vendor is acquired?

    Culture and values alignment

    • How does your team talk about customers internally, as accounts or as partners?
    • What's a decision your company made that cost you revenue but was the right call for customers?

    Company mission / vision

    • Where do you see this product in five years, and does that vision match where my organization is headed?
    • What won't you build, even if customers ask for it?

    Implementation & onboarding philosophy

    • What does a realistic implementation timeline look like for an organization my size, not the best-case number in your marketing?
    • Who owns onboarding: an internal team, a partner, or a mix, and how does that affect accountability if something goes wrong?
    • What's the single most common reason implementations with your platform go sideways, and how do you prevent it?

    The partnership is the product

    Every ITSM platform on the market can mostly check the same feature boxes. What separates a good five-year relationship from a bad one rarely shows up in a demo. It shows up in how a vendor responds to your requests, how seamless your interactions are, and whether your feedback changes anything.

    Ask these questions before you sign. The answers you get, and the ones a vendor avoids, will tell you more than any feature walkthrough ever could.

    Want a closer look at how Xurrent approaches implementation and long-term partnership? Explore Xurrent's customer success stories.

    Frequently Asked Questions

    Customization boundaries matter because over-customization can create serious problems at upgrade and migration time. One organization left Xurrent for a vendor who agreed to build a one-off custom feature; when it came time to move from testing into production, the data transition broke and the implementation fell apart entirely. Asking a vendor when they have said no to a customization request — and why — reveals whether they are protecting you from that outcome or simply telling you what you want to hear.

    Xurrent ships product updates on a weekly cadence. Rather than releasing changes directly into production, updates are first deployed to a QA environment where customers can review and shape what ships before it reaches their live instance. This approach is meaningfully different from vendors that upgrade once or twice a year, and it gives customers visibility and direct input into the release process rather than simply receiving changes after the fact.

    Post-sale support questions should uncover whether support is delivered by the vendor directly or handed off to a partner or outsourced team once the contract is signed, and what the escalation path looks like for a critical issue at 2 a.m. These distinctions matter because the quality of support experienced during the sales cycle may not reflect what an organization encounters after go-live, particularly during high-stakes incidents that happen outside normal business hours.

    A named post-go-live contact means an organization's needs are tracked by someone who understands the account, rather than being routed to a general queue. The right question to ask is how the vendor measures whether a customer is actually succeeding with the platform — not just whether the contract renews. That question separates vendors who treat customers as accounts from those who treat them as long-term partners.

    The most direct test is asking a vendor to show you something that shipped in the last year because a customer requested it. Beyond that, organizations should ask what the realistic path looks like from a feature request to a shipped update, and who makes those decisions. A vendor that can point to a concrete example of customer-driven development is demonstrating accountability; one that responds with vague answers is signaling that roadmap influence may be limited in practice.

    Xurrent does not publish fixed pricing tiers and instead builds plans around each organization's individual needs. The company's licensing is designed to avoid surprise overage penalties if a team temporarily exceeds its licensed user count. This model contrasts with vendors that automatically charge for every overage, and it makes asking any ITSM vendor directly about overage policies and hidden costs for support tiers, API access, or add-on modules a worthwhile part of any evaluation.

    Choosing an ITSM platform is the start of a multi-year relationship, not a one-time transaction. Feature comparisons dominate evaluations because features are visible and easy to score, but the factors that determine long-term success — how support responds at 2 a.m., whether the roadmap moves based on customer input, what an upgrade feels like eighteen months in — rarely appear in a 45-minute demo. Evaluating vendors on those dimensions requires different questions than a feature checklist provides.

    A platform designed primarily for 50,000-seat global enterprises carries structural assumptions that tend not to fit a 1,000-person IT team, and vice versa. Design priorities, default configurations, and roadmap decisions all reflect the vendor's primary customer type. Xurrent has been recognized on industry lists specifically for building its roadmap around midsize organizational needs, which is a meaningfully different design center than platforms engineered first for the largest enterprises.

    The most important thing is to ask for a realistic implementation timeline for an organization your size — not the best-case figure from marketing materials. Organizations should also ask who owns onboarding: an internal vendor team, a partner, or a combination, since that directly affects accountability if something goes wrong. Asking what the single most common reason implementations go sideways is — and how the vendor prevents it — rounds out a complete picture of implementation risk.

    Vendor culture and values reveal how a company behaves when there is no immediate commercial incentive to behave well. Asking how the vendor talks about customers internally — as accounts or as partners — and asking for an example of a decision that cost the company revenue but was the right call for customers, surfaces real character. Xurrent's own opening example illustrates this principle: the company declined a one-off customization request, lost the customer temporarily, and the competing vendor's implementation eventually failed.