I have worked inside a lot of veterinary hospitals.

I’ve also had the privilege, and I use that word loosely, of not only working inside a lot of different PIMS but also being the person who had to take a new system live with a team that didn’t ask for it, wasn’t ready for it, and had about forty-eight hours of training before go-live. I’ve watched CSRs open browser tabs and sticky notes in the same breath. I’ve watched team members develop elaborate paper backup systems because the computer system couldn’t do what they actually needed it to do.

I’ve sat in the meetings where someone from above asked how the transition was going, and watched managers say “it’s good, we’re right on time” because they didn’t know how to explain what was really happening, and also because no one had given them language for what “not going well” even meant, nor did they really know what was ahead of them. Because no one taught them what questions to ask or what to look for before they ever even demoed the system, let alone while they were going through the process.

That’s the moment this week’s episode starts with.

This week on Leading Veterinary Teams On Air, I’m talking about something that doesn’t get nearly enough airtime in veterinary leadership conversations: software decisions, who makes them, and what it actually costs the team when those decisions go wrong.

The episode is called What Veterinary Leaders Need to Know Before Changing PIMS, and I’m joined by Adam Wysocki of VetSoftwareHub.com.

If your hospital is considering a PIMS transition, adding AI tools, or trying to clean up the workarounds your team has quietly built, I hope you listen to this one.

Thanks for reading! This post is public so feel free to share it.

After talking to Adam, the part that I keep coming back to is something that shows up in every hospital I have ever worked in or consulted with.

A PIMS decision, or any major software decision, often gets made at a level that is several steps removed from the people who will use it every single day. In corporate environments, leadership from above evaluates demos while Finance approves the contract, IT handles the technical setup, and then the team shows up on Monday handed a new way to do every single thing. In some situations the hospital team will be included in the demo, but in many cases they are told which program they are getting. Privately owned, independent practices don’t experience this in the same way structurally, but the teams often still feel exactly the same when they are left out of the process entirely. Because being excluded feels the same regardless of who made the call.

The people in the demo are rarely the ones who enter treatments at 2am during an ICU shift. They’re rarely the ones who need an invoice to generate in under thirty seconds because there are four clients waiting and one impatiently tapping their credit card at the counter, complaining that they have to get to their next thing. They aren’t the ones who wind up building the workaround when the system doesn’t do the thing it was promised to do in the way the team actually needs it done.

And nobody is really tracking the cost of those workarounds. Not in dollars, in time, and most definitely not in the quiet frustration that builds every single shift when the tool that is supposed to help you makes your job harder instead.

That frustration? I call it implementation trauma, and it doesn’t go away when the system stabilizes. It becomes part of how your team talks about the decisions that are made by leadership. It becomes the evidence, real or perceived, that the people running the hospital don’t actually understand what the team actually does. And it becomes the thing your team reaches for the next time you try to implement something new.

That is an operational trust problem. And it’s much harder to recover from than a bad software choice.

I want to say this clearly because I think it gets overlooked all too often.

Every sticky note, every spreadsheet that lives outside of the PIMS, and every “we just text each other” and “we have a paper log for that” and “the system can’t do it so we do it this way” is … data.

It’s telling you exactly where your systems are failing your people. These aren’t people problems. They’re problems within the system that is failing the very people you’re supposed to be supporting.

Not where your people are failing your systems, but where your systems are failing your people.

That distinction matters because when a team builds a workaround, it’s not a sign of poor training or low compliance, it’s a sign that the tool we got to help the workflow didn’t actually fit it in the first place. And not unsurprisingly, your team cared enough about patient care and the client experience to find a solution around the attempted solution. Instead of reducing friction, your team absorbed the ever-growing gap.

It is because they care, that they will always absorb the gap.

The real question is whether you even realize the gap exists.

The thing I keep thinking about as AI starts to show up in more and more veterinary software conversations is how AI isn’t going to save a broken implementation or fix a workflow that was never mapped to begin with. And AI certainly isn’t going to replace the judgment of a credentialed technician who knows the patient, knows the context, and knows what the computer cannot possibly know.

What AI is going to do is make your existing gaps a lot more visible. If your systems are already fractured, and your team is already compensating for software that doesn’t match the work, adding an AI layer on top of that doesn’t solve the problem. It speeds up the parts that were already working and exposes the parts that weren’t.

That’s not a technology problem. It’s a problem with the underlying infrastructure that leadership has in place. The leaders who are paying attention right now are not asking “what AI tool should we add?” They’re asking “do we actually understand our own workflows well enough to know what we’d want AI to support?”

That’s the right starting point. Don’t add AI for the sake of adding AI, or you’ll wind up more overwhelmed than when you started.

One. Make a list of every workaround your team currently uses. Things on that list might include:

Write down every single one. Don’t judge it, just list it out because every workaround is data, and right now you probably don’t have it written down anywhere.

Two. Ask your team one question: “What part of our software slows you down the most?” Then listen. Not to fix it and not to explain why it is the way it is. The goal is not to defend a decision that was made three years ago. Just listen and let them tell you where the friction lives.

Three. If you’re considering a software change right now: do not book demos first. Map your workflows first. I mean it. Walk the actual process. Understand what the team actually does before you evaluate whether a tool can support it. If I learned anything from my conversation with Adam, it was this. That one step alone will change every conversation you have with a vendor.

The software is rarely what is frustrating your team. The root of what’s frustrating your team is the bad implementation. And bad implementation almost always traces back to a decision made without the people who will live inside the outcome. That’s something you have the ability to change for the next one. And if you don’t know where to start, www.VetSoftwareHub.com has options for just about every software you could imagine and they are always adding more!

I’m thankful to Adam for sharing this conversation with us! It really got me thinking and I hope you found it helpful too! If you took a moment to check out the podcast, would you do me a huge favor and subscribe? That way Youtube and all of the other podcast platforms knows you’re enjoying the podcast and you’ll never miss another episode!

Before we go - I wanted to apologize really quick to anyone who has taken the CLARITY assessment , clicked on one of the links at the end and found a dead end. I’m incredibly thankful to those who reached out to let me know that the links weren’t working… They work now! If you’re interested in a call to review your results, or the CLARITY cohort… here’s what you can do!

Until next time, lead where you are. Even when it’s uncomfortable. Especially when it’s uncomfortable.

-Suzanne

Suzanne Thomas is the founder of Leading Veterinary Teams, a platform built for veterinary managers and frontline leaders who were promoted without a playbook.