Part 3 Support & Governance

When something goes wrong, will your vendor actually help? How to demand SLAs with teeth and escalation procedures that stick.

📅 February 22, 2026 ⏱️ 17 min read

The Complete Framework

This is Part 3 of a 5-part series evaluating library technology vendors. Each part examines one critical domain:

Part 1: Stability

Part 2: Contract Terms

✓ Part 3: Support & Governance

Part 4: AI Considerations

Part 5: Accountability

The Question

Something breaks. Your catalog is down. Staff can't access circulation. A critical workflow stops. You call your vendor.

Will they actually help?

Not "do they pretend to help." Not "do they say the right things." Will they actually show up, diagnose the problem, and fix itwith urgency proportional to the damage?

This is support governance. It's the difference between a vendor that crumbles when things get real and one that holds the line.

Why This Matters

Most vendor failures aren\'t about architecture or features or pricing. They\'re about support.

A library can live with a mediocre search algorithm. They can\'t live with a vendor who disappears when the system is down. A confusing UI is annoying. A support team that doesn\'t know how to help is destructive.

Here's what happens when support breaks:

Downtime extends from hours to days because nobody knows how to escalate
Your account transitions to a new manager, and institutional knowledge vanishes
Support promises "we'll call you back" but nobody ever does
You discover SLAs have no teethno penalties, no credits, no accountability
Staff get burned out fighting the same issues repeatedly because the vendor never fixes the root cause

In the worst cases, libraries have lost circulating books, patron data, and entire workflowsnot because the technology failed, but because the vendor couldn\'t or wouldn\'t help.

What to Evaluate

1. SLAs With Teeth

An SLA is a Service Level Agreement. It defines response and resolution times. The problem: most SLAs vendors offer are soft promises with zero consequences.

Here's what to demand:

Severity Level	Impact	Response Time	Resolution Time
Critical	System down, no workarounds	1 hour (24/7)	4 hours or escalation
High	Major feature unavailable	2 hours (business hours)	8 hours or escalation
Medium	Feature partially degraded	4 hours (business hours)	24 hours or escalation
Low	Minor issues, full workarounds	24 hours	5 days or escalation

But here's the critical part: SLAs must have penalties. The vendor should commit to:

Service credits: If they miss the SLA, you get a % credit on your contract (typically 5-25% depending on severity)
No manual claim process: Credits are automatic, not something you have to beg for
Monthly reporting: The vendor sends you a report showing response times and any SLA misses

Red flag: If a vendor says "we aim to respond within 4 hours" instead of "we will respond within 4 hours," they\'re not committing to anything. "Aim" is not an SLA. It\'s a hope.

2. Uptime Guarantees

Beyond response times, demand uptime guarantees on the system itself:

99.5% uptime minimum (this allows ~3.6 hours of downtime per month)
Scheduled maintenance windows should be outside uptime calculations
Maintenance notice must be provided 72 hours in advance with specific dates/times
Service credits for uptime failures: 5% credit for 98.0-98.9%, 10% for 97.0-97.9%, 25% for below 97%

Ask for the vendor\'s actual uptime history. If they can\'t show you 99%+ for the past 12 months, they can't promise it going forward.

3. Vendor Staff Continuity

This is invisible but critical. Every time your account transitions to a new support manager or technical specialist, you lose knowledge.

What to evaluate:

Dedicated account management: You have a named contact who knows your library
Staff turnover rates: Ask the vendorwhat's their average tenure for support staff? (Industry average is ~2 years; good vendors are 3-5+ years)
Transition process: When staff change, is there documented handoff? Do they introduce the new person? Do they stay available during transition?
Escalation path: Who do you contact if your primary contact isn't available? Is there a backup?

Staff continuity matters because:

Your primary contact understands your specific implementation, configuration, and workflows
They know your library's previous issues and can anticipate problems
They have the trust and relationship to move fast when you call

4. Training and Onboarding

Good support starts before you ever need to call. What's included:

Initial implementation training: How long? Who attends? Is it on-site or remote?
Staff training program: Can your staff get trained? Is there a certification?
Documentation quality: Is it searchable, up-to-date, with screenshots and workflows?
Video tutorials: For common tasks, are there short instructional videos?
Knowledge base search: Can your staff find answers themselves without calling support?
Annual refresher training: Are staff kept up-to-date on new features and changes?

Libraries with poor onboarding tend to develop dependency on support. They call for simple questions. Good onboarding means your staff can solve 80% of problems themselves.

5. Escalation Procedures

This is the most-overlooked piece. When support can't solve something, what happens?

Get the escalation flow in writing. It should look like this:

Level 1 Support (Frontline)
- Response within 1-2 hours
- Can handle configuration, basic troubleshooting, account issues
- Escalates to Level 2 if issue isn't resolved in first contact or requires engineering
Level 2 Support (Engineering)
- Response within 2 hours
- Can diagnose system issues, review code, check server logs
- Escalates to Level 3 if it's a product bug or requires development
Level 3 Support (Product/Development)
- Response within 4 hours for critical issues
- Can fix bugs, prioritize features, make architectural decisions
- Reports back to your account manager with resolution plan

What to ask: "If I find a bug that breaks our workflow, what happens? How does it get to the development team? How long before I hear back?"

Red Flags That Matter

Soft language in SLAs: "We aim to," "we strive to," "we endeavor to." These are promises with no teeth. Demand "we will" and "guaranteed."

No uptime guarantees or history: If the vendor won\'t commit to uptime percentage or won\'t share their historical data, they're hiding something.

SLA credits require you to ask: If you have to submit a claim to get a credit, most libraries never will. Credits must be automatic.

High support staff turnover: If the vendor can\'t tell you their staff retention rates, assume it\'s bad. High turnover = losing institutional knowledge constantly.

No named account manager: "Support is available" is code for "nobody owns your relationship." You need a person.

Escalation doesn\'t exist: If you ask "what happens when support can\'t solve this?" and they say "we\'ll figure it out," they haven\'t figured it out.

Onboarding is extra: If implementation training or ongoing staff training costs extra, that's a sign support is an afterthought.

Poor documentation or knowledge base: If you can\'t find answers online, the vendor is making people call. That\'s inefficient and a sign they don't invest in self-service.

Mission Lens: Support Disparities Hurt the Most Vulnerable

Who bears the cost of bad support?

Small and rural libraries have the smallest IT staff. When their vendor disappears, they can\'t absorb the load. A 2-person library losing their ILS for 48 hours isn\'t an inconvenienceit's a disaster.

Poor and under-resourced libraries can\'t afford to keep staff waiting around for vendor callbacks. They can\'t hire consultants to debug issues. Their margin for error is zero.

Libraries in economically depressed areas often work with vendors because they can\'t afford in-house expertise. Those vendors have disproportionate power. Bad support isn\'t just inconvenientit's exploitative.

This means good support governance is equity work. When you demand SLAs with penalties, you're protecting the libraries who can\'t push back alone.

What to Do Right Now

Request their SLA document. Read it carefully. Look for weak language and missing penalties.
Ask about uptime history. Request 12-month uptime data, broken down by month.
Identify your account manager. Ask for their name, contact info, and backup contact.
Get the escalation flowchart. It should be clear, written down, and have specific timelines.
Sit through a training session. See how clear and professional it is. This is predictive of support quality.
Check references with similar libraries. Ask specifically: "When you called support with an urgent issue, how long did resolution take?"

Support governance is the safety net. You hope you never need it. But when you do, it determines whether you recover in hours or days.

← Part 1: Stability Financial health and market position.

← Part 2: Contract Terms Protecting your data and rights.

✓ Part 3: Support & Governance SLAs, uptime, and escalation procedures.

Part 4: AI Considerations → Evaluating AI features and risks.