The Support Question Every Vet Practice Manager Should Ask (But Most Don't Until It's Too Late)

"Our support is amazing."

If you've sat through more than two veterinary software demos, you've heard this line. Maybe with a smile. Maybe with a hand wave toward a "97% satisfaction score" on a slide.

Here's what that line actually means: nothing.

Because "amazing support" doesn't show up in a PowerPoint deck. It shows up on a Friday afternoon when your server crashes, your phones are ringing, and the vendor's chatbot keeps asking if you've tried restarting.

I've spent 35+ years building and selling software and 10 years in veterinary services, both as a CEO running a software company, and now helping practices evaluate their options. And I can tell you this: support quality is the feature that determines whether your team loves the software or resents it.

Let me show you how to evaluate veterinary software support before you sign—using real tests, not promises.

---

Why Support Isn't Just a "Nice-to-Have" Feature

Most practice owners and managers think about support as something you need occasionally—a safety net for when things go wrong.

That's backwards.

In a veterinary practice, support affects everything:

Staff morale (and turnover)
Nothing burns out a CSR faster than fighting with software that doesn't work while clients are waiting. When your team knows they can get help quickly, they stay calm. When they know they'll be stuck in ticket purgatory, they start updating their résumés.

Client experience
Missed appointment reminders because the integration broke? Dropped calls because the phone system won't sync? Delayed callbacks because no one can access the voicemail? That's the support failures that your clients experience as your failure.

Revenue
Slow invoicing, missed charges, payment processing failures—every one of these is a support issue that hits your bottom line.

Medical care
Delayed records, incomplete patient histories, workflow chaos during a critical case—this is where bad support crosses from "annoying" to "dangerous."

The real question isn't "does this vendor have support?"
It's "Does this vendor have support that works when my clinic is slammed, and I need an answer now?"

---

What "Good Support" Actually Looks Like (Hint: It's Not What Vendors Say in Demos)

Let's get practical. Most clinics don't need perfect support. They need predictable, respectful, competent support in the moments that matter.

Here's what that looks like in real life:

You can reach someone who actually knows veterinary clinics

Generic SaaS support can get you nowhere fast. "Have you tried clearing your cache?" doesn't help when you need to know how to handle a client who was double-charged during checkout rush.

Good veterinary software support means the person on the other end understands CSRs, techs, doctors, and practice managers—and doesn't need a 20-minute explanation of what "SOAP notes" are.

Problems get owned (no finger-pointing)

The worst support experiences happen when issues involve integrations. Bad vendors blame the other company. Good vendors own the problem until it's solved, even if they have to coordinate with a partner.

If your payment processor and your PIMS can't agree on who's responsible when transactions fail, guess who becomes the messenger? You.

You get clear next steps (not vague reassurance)

"We're looking into it" is not a status update. "Our engineering team is testing a fix now, and we'll update you by 2pm with either a solution or a workaround" is a status update.

The two types of support (and why you need both)

Most vendors split support into two buckets, even if they call them different things:

Customer Success: adoption, training, workflow optimization, best practices, check-ins, renewals
Technical Support: bugs, outages, integrations, data issues, permissions, performance problems

Great vendors are clear about who does what and how issues get escalated. Bad vendors leave you guessing whether your problem is "a success team thing" or "a support ticket thing" while your clinic sits in limbo.

---

The Questions That Separate Real Support From Marketing Support

During demos, vendors will say whatever it takes to get them to the contract. Your job is to move past the promises and learn how support actually works.

Here's what to ask—and what answers should concern you.

Support hours, channels, and coverage

1. What are your support hours (and what time zone)?
"Business hours" mean different things in different time zones. If you're in California and they're in New York, their "9-5" ends at 2 pm your time.

2. What channels can I use to get support?
Phone, chat, email, ticketing system—some vendors offer all of them, some make you submit a ticket for everything. Know what you're getting before you need it.

3. Is there after-hours support for emergencies?
And more importantly: what counts as an emergency? If your definition and theirs don't match, you'll be frustrated at 7 pm on a Saturday when the system is down.

4. Do you offer weekend support, or is it "best effort"?
"Best effort" usually means "maybe, if someone happens to check their phone."

5. Will we have a dedicated account manager, or is it shared support?
This matters more than you think. A dedicated person knows your clinic, your setup, and your history. A ticketing queue doesn't.

Ownership and escalation (where most vendors fumble)

6. What's your escalation path for clinic-blocking issues?
If the system goes down during an appointment rush and you can't check in patients, who do you call? How fast do engineers get involved?

7. How do you handle integration failures?
This is the question that reveals maturity. When your online booking system stops syncing with your PIMS, who owns triage? Who coordinates the fix? Who keeps you updated?

If the answer is "contact the other vendor," run. That's not a support plan. That's a support tax.

Clarity and communication (the difference between anxiety and confidence)

8. Do you provide regular updates during incidents?
"We're working on it" is fine for the first update. But if I don't hear from you for 6 hours while my clinic is stuck, I'm going to assume you forgot about me.

9. Do you have a public status page?
Or at least a predictable way to communicate when things break? The worst support experiences happen when you don't know if the problem is on your end or theirs.

10. What information do you need from us to diagnose issues quickly?
Good vendors tell you upfront: screenshots, timestamps, affected users, sample client records, and error messages. Bad vendors play 20 questions over 3 days.

Training and prevention (the support that reduces tickets)

11. What training is included, broken out by role?
A one-hour webinar doesn't cut it. CSRs need different training from doctors. Managers need reporting training. What's actually included?

12. Is there a knowledge base, and is it actually useful?
Some knowledge bases are great. Some are a graveyard of outdated articles written by engineers for engineers.

13. How do you communicate new features?
Surprise changes break workflows. How do you avoid turning "improvements" into chaos?

Pro tip: Ask for all of this in writing. A confident vendor won't be offended. They'll be relieved you're taking support seriously.

---

Support SLAs: What Actually Matters (And What's Just Marketing)

Many vendors use "SLA" as a magic word, implying they'll fix your problems quickly.

Let's clear up the confusion.

Response time ≠ resolution time

Response time: How quickly you get a meaningful first update from a human (not an auto-reply)
Resolution time: How long it takes to actually solve the issue (or give you a stable workaround)

A vendor can "respond in 30 minutes" and still leave you stuck for days. Make sure your contract and expectations cover both.

Severity levels (in language that makes sense for clinics)

Most vendors have severity levels. The problem is that they don't always define them clearly—or their definitions don't align with your reality.

Here's a clinic-friendly framework:

Severity 1 (Clinic-Blocking): Core workflows are down or unsafe
Examples: Can't check in patients, can't charge out, can't access medical records, payment processing is completely broken, scheduling is down, client communication channels are dead

Severity 2 (Major Degradation): System is usable but painful
Examples: Major slowdowns, integrations failing for many clients, reports broken during end-of-day close, intermittent failures that disrupt workflow

Severity 3 (Standard Issue): Annoying but not urgent
Examples: How-to questions, minor bugs, small configuration changes, cosmetic issues

You don't need to adopt these exact labels. You need to know:

• What the vendor treats as urgent

• How they behave when urgency hits

• Whether their definition matches yours

Red flag: If they can't clearly define severity levels, they probably don't treat emergencies differently from regular tickets.

---

How to Test Support Before You Buy (The 7-10 Day Reality Check)

This is the most critical section in this entire post.

If a vendor can't handle realistic questions during the sales process, they definitely won't magically improve after you sign a 3-year contract.

Most practices skip this step. Don't.

Step 1: Request a "support trial"

You don't need full product access to test support. You just need permission to submit real questions and see how they respond.

Here's an email template you can copy:

---

Subject: Support evaluation before purchase

Hi [Name],

Before we finalize our decision, we want to evaluate support quality the same way we assess features. Over the next 7-10 days, we'd like to submit five realistic support requests covering workflow, billing, reporting, and one integration scenario.

Can you confirm:

• The best channel to submit these requests

• Your expected response windows for urgent vs. standard issues

• Who will own escalation if a request requires engineering or an integration partner

Thanks,
[Your name]

---

A vendor that welcomes this request is confident in their support. A vendor that pushes back is telling you something important.

Step 2: Submit 5 realistic test tickets

Don't waste this on softball questions. Use scenarios that represent real clinic pain:

1. Permissions and role setup
"We need a CSR role that can schedule and send reminders, but cannot change pricing or edit medical notes. What's the recommended permission configuration?"

2. End-of-day reporting
"We need a daily report showing appointments completed, invoices closed, and payments collected—broken out by provider. What's the fastest way to produce this, and can it be automated?"

3. Billing edge case
"A client was charged twice during checkout. What are the exact steps to fix this, and how do we prevent it from happening again?"

4. Reminders and communications workflow
"We want to reduce no-shows. What reminder cadence do you recommend, and how do we track success (and failures) inside the platform?"

5. Integration scenario (this is the one that reveals maturity)
"If [integration partner] stops syncing for two hours, how do we find out? Who do we contact? What's the recommended workaround? And how is this incident communicated to us?"

Step 3: Track what actually happens

You're not measuring "niceness." You're measuring usefulness.

For each ticket, track:

• Time to first meaningful response (not an auto-reply that says "we got your ticket")

• Time to a useful next step (explicit action, relevant help doc, call scheduled, workaround provided)

• Time to resolution (or stable workaround)

• Quality of communication (clear updates, ownership, no blame-shifting)

• Empathy and respect (especially if your question sounds frustrated or urgent)

Here's a simple tracking table you can paste into a doc:

Step 4: Do one "stress test" call

Select one ticket and request a brief call to discuss it.

You're evaluating:

• How quickly you can get time with a real human

• Whether they understand your clinic context (or need everything explained from scratch)

• Whether they can translate "software speak" into "clinic steps."

• Whether the call results in a clear plan (not more "we'll look into it")

If it takes three follow-ups to schedule a 15-minute support call before you're even a customer, that's precisely what post-sale reality will feel like.

---

What Great Vendors Do During Outages and Integration Failures

Every system will fail eventually. Every integration will break at some point.

The difference between good and bad vendors isn't whether problems happen—it's how they handle them when they do.

What to expect during an incident

Ask vendors to walk you through their incident process. A strong answer includes:

How they detect issues
Internal monitoring, automated alerts, dashboards that catch problems before clinics do

How they notify you
Status page updates, email alerts, in-app banners—not "you'll notice when it stops working"

How often they communicate
Example: "Every 30-60 minutes for clinic-blocking issues until resolved"

What workarounds they provide
Even partial workarounds (like manual entry while automation is down) show they're thinking about your reality

Post-incident communication
What happened, how it was fixed, and what they're doing to prevent it from happening again

The integration ownership question (where support falls apart)

Integration problems are where vendors love to blame each other. You end up playing telephone between two companies while your clinic sits broken.

Ask this directly:

"When an integration fails, who owns:

• Triage (figuring out what's broken)

• Communication to me (keeping us updated)

• Workaround guidance (what we should do now)

• Partner coordination (fixing the actual problem)

• Making sure we're not the messenger between two vendors pointing fingers at each other"

If the answer is anything close to "you'll need to contact the other vendor too," that's a massive red flag.

Good vendors coordinate on your behalf. Bad vendors make you the project manager of your own crisis.

---

Contract Language That Protects You (Without Turning This Into a Legal Battle)

You don't need to lawyer-up your contract. You just want basic protections that align incentives and set clear expectations.

Here are practical asks that clinics can often get (this isn't legal advice, just buyer protection that reduces pain):

1. Attach the support policy and SLA as an exhibit
If it's not in writing, it's not real. Make the "amazing support" promises part of the contract.

2. Define severity levels in plain language
Even simple definitions help prevent disputes about what counts as urgent.

3. Require incident communication standards
Example: "Clinic-blocking incidents will receive status updates at least every 60 minutes until resolved, or a workaround is provided."

4. Escalation commitments
Example: "P1 issues will be escalated to engineering within 30 minutes of confirmation."

5. Implementation and onboarding commitments
If onboarding is critical to your success, put deliverables and timeline expectations in writing.

6. Clear ownership for integration incidents
Even something simple like "Vendor will coordinate with integration partners on behalf of the clinic" can save massive headaches.

---

Red Flags That Should Stop a Purchase Cold

If you see these patterns during the sales process, they'll be worse after you sign:

• No clear support hours, no written policy, no escalation path
  If they can't articulate this during a demo, they don't have a process.
  
  

• "We respond quickly" with no actual definitions
  What does "quickly" mean? 10 minutes? 2 hours? 2 days?
  
  

• Support reps who can't speak in clinic workflows
  Everything is generic software jargon. They don't understand your reality.
  
  

• Integration issues are "not our problem"
  You'll be the one stuck between vendors pointing fingers.
  
  

• No incident communication plan
  "We'll let you know if something's wrong" is not a plan.
  
  

• "Just submit a ticket" is the only answer for urgent issues
  Sometimes you need a phone call. Sometimes you need a human now.
  
  

• Heavy pressure to sign before support questions are answered
  If they're rushing you past the support conversation, there's a reason.
  
  

A vendor that welcomes tough support questions is confident in their support. A vendor that deflects them is telling you everything you need to know.

---

The One-Page Support Evaluation Checklist

Print this. Use it during demos. Check boxes as you go.

Support Access

• [ ] Support hours clearly defined (with time zone)

• [ ] Channels are clear (phone, chat, ticketing)

• [ ] After-hours emergency process exists for clinic-blocking issues

• [ ] Weekend coverage is defined (not just "best effort")

SLAs and Expectations

• [ ] Response time expectations defined for urgent vs. standard

• [ ] Resolution time or workaround expectations discussed

• [ ] Severity levels defined in clinic-friendly language

• [ ] SLA is attached to contract (not just mentioned verbally)

Ownership and Escalation

• [ ] Escalation path is documented

• [ ] Engineering escalation process is clear and fast

• [ ] Integration incident ownership is clear (they coordinate, not you)

Communication Quality

• [ ] Vendor commits to update frequency during incidents

• [ ] There's a predictable incident notification method (status page, email, etc.)

• [ ] Tickets include clear next steps (not vague "we're looking into it" responses)

Training and Prevention

• [ ] Role-based training plan exists (CSR, tech, doctor, manager)

• [ ] Knowledge base is usable by front desk staff (not just IT people)

• [ ] New features are communicated responsibly (no surprise workflow changes)

Pre-Purchase Test

• [ ] We ran a 7-10 day support test with 5 realistic requests

• [ ] We tracked first response time and time to useful next step

• [ ] We tested one escalation scenario and one integration scenario

• [ ] We had at least one real-time conversation (phone/video) with support

---

Final Thoughts: Support Is the Feature You Use On Your Worst Days

When your clinic is slammed, appointments are running late, a client is upset, and something breaks—support becomes the most important feature in your software.

Not the fancy AI features. Not the mobile app. Not the integrations.

Support.

Because on your worst day, support is the difference between "we'll figure this out" and "I can't believe we're stuck with this for three more years."

Don't accept vague promises. Don't skip the support test. Don't assume "everyone says support is good" means it actually is.

Run the test. Ask the hard questions. Require clear ownership, especially for integrations.

If a vendor earns your trust on support, everything else, onboarding, training, adoption, and ROI … gets easier.

And if they can't handle a few realistic questions before you sign?

That's not a red flag. That's a dealbreaker.