Feature comparisons dominate most software evaluations, but the experience of using a product over three or five years is shaped more by what happens when something breaks. A vendor with a slightly shorter feature list and a support desk that answers the phone in two minutes will outperform a feature leader whose tickets sit for days. Support quality is harder to compare than features because vendors describe it in similar language. It is not impossible to compare; it just requires testing rather than reading.
Why support decides more than features
Every system fails at some point: an integration stops, an update changes a workflow, a user locks themselves out at 7:55 a.m. What matters in those moments is whether help is reachable, competent, and empowered to fix the problem. Poor support has compounding costs. Staff develop workarounds instead of waiting for fixes, problems are under-reported because reporting them feels futile, and the organization's knowledge of the product stalls at whatever the implementation team taught. Good support has the opposite effect: issues are resolved, users learn, and the product's value grows over time.
Support models and tiers
Vendors package support in tiers, and the differences between tiers are often larger than the differences between vendors. Typical structures include a basic tier (email or portal tickets during business hours, self-service knowledge base), a standard tier (phone support, defined response times by severity, business-hours coverage in the vendor's time zone), a premium tier (extended or 24/7 coverage, faster response, a named account or technical manager), and enterprise arrangements with dedicated staff. Ask which tier is included in the quoted price, what each upgrade costs, and whether the tier can be changed mid-contract. Also ask who delivers support: the vendor's own employees, an outsourced help desk, or a reseller. Each can be excellent, but the answer tells you who will be on the line.
Match the tier to your hours. A clinic that opens at 7 a.m. Eastern with a vendor whose support opens at 9 a.m. Pacific has a three-hour gap every morning. Confirm coverage in your local time, including weekends if you operate then.
What to measure
| Dimension | Question | Evidence to request |
|---|---|---|
| Reachability | Can a user reach a person by phone during our hours? | Published hours; test calls |
| Response time | How quickly is a ticket acknowledged by severity? | Written SLA; average and 90th percentile actuals for the last year |
| Resolution time | How quickly are issues resolved, not just acknowledged? | Median time-to-resolution by severity |
| First-contact competence | Does the first person who answers know the product? | Test tickets with product-specific questions |
| Escalation | How does an unresolved issue reach engineering or management? | Documented escalation path with names or roles |
| Self-service | Is the knowledge base current, searchable, and specific? | Search it yourself for three real questions |
| Transparency | Is there a public status page and release notes? | Status page history; last six release notes |
| Continuity | Will we have a consistent contact after go-live? | Account management model; turnover |
Testing support before you sign
The most reliable evaluation is a live test. During the trial or proof-of-concept period, do the following:
- Submit real tickets. Use the standard support channel, not your sales contact, and ask two or three product-specific questions of varying difficulty. Record time to first response, whether the answer was correct and complete, and how many exchanges it took.
- Call the support line at the start of your business day and again at the end. Note hold time and whether the person who answered could help or only take a message.
- Search the knowledge base for the questions you submitted. A good knowledge base would have answered at least one of them without a ticket.
- Read the status page history for the past year. Frequent incidents are informative; so is a status page with no incidents, which may mean incidents are not posted.
- Ask for support metrics in writing. A vendor confident in its support will share ticket volume, response and resolution times, and customer satisfaction scores. Reluctance is a data point.
What references can tell you
Vendor-supplied references are chosen because they are happy, but they can still be useful if you ask specific questions: describe the last serious problem you had and how it was resolved; how long did your worst ticket take; have you ever escalated, and what happened; has your account contact changed in the last year; and what would you change about support if you could. Ask to speak with a customer of your size and type, and look for users of the product in professional forums or associations who are not on the vendor's list. Their descriptions of support are usually more candid.
Contract terms that protect you
- Written response and resolution targets by severity level, with the definitions of each severity.
- Coverage hours in your time zone, including holidays and weekends if relevant.
- An escalation path naming roles and time triggers.
- Remedies for missed commitments, such as service credits, and a termination right for chronic misses.
- Tier lock. The support tier you buy cannot be reduced or repriced during the term.
- Named contact or account manager for the first year, if that was part of the pitch.
If the vendor will not put a support term in writing, assume it does not exist. Sales promises about support are the promises most often forgotten once implementation begins.
A simple scorecard
Score each vendor from one to five on reachability, first-response time, resolution quality, escalation clarity, self-service quality, transparency, and contract commitments. Weight the dimensions by what matters most to your organization; a small practice with no IT staff might weight reachability and first-contact competence heavily, while a multi-site organization might emphasize escalation and account continuity. Then compare the weighted totals alongside the feature and price comparison. When a strong feature leader scores poorly on support, that is the moment to decide whether the features are worth the cost of being on your own when they fail.
Common questions
What is the difference between response time and resolution time?
Response time is how quickly the vendor acknowledges a ticket, usually by a person rather than an automated reply. Resolution time is how long until the problem is fixed. Many vendors commit only to response time, so ask for actual resolution data by severity level before signing.
Should we test support during a trial, and how?
Yes. Submit real product questions through the standard support channel, call the support line at the edges of your business day, search the knowledge base for the same questions, and review the status page history. Record what happened and compare across vendors.
Is 24/7 support necessary for a medical practice?
It depends on when you operate and how much downtime you can absorb. A practice open weekdays during standard hours may be well served by business-hours support with clear coverage in its local time zone. Organizations with weekend or extended hours, or with critical systems, should weigh extended coverage more heavily.
Can support terms be negotiated into the contract?
Usually yes. Response and resolution targets, coverage hours, escalation paths, remedies for missed commitments, and a lock on the support tier are all reasonable requests. Terms not written into the agreement are difficult to enforce later.