Kandji vs Rippling IT for a Multi-Hospital Vet Group

Digital radiography, ultrasound, and lab analyzer systems typically run on a Windows PC that the equipment vendor configured and often insists on servicing directly. Installing management software on that machine can conflict with the vendor's own support agreement or void a warranty, so confirm the terms before you touch it.

That leaves front-desk terminals, practice management workstations, and any tablets used for treatment notes as the fleet you're actually deciding a platform for. It's usually smaller than the full device count in the building suggests, and knowing that number before you start comparing platforms keeps the pricing conversation honest instead of budgeting against every machine in the building.

Get this in writing from each equipment vendor rather than assuming. Some vendors are fine with basic patch management as long as their own application isn't touched, while others want the whole machine untouched; the difference matters when you're deciding how much of the building's fleet a platform actually needs to cover.

Some multi-hospital groups standardize on Mac for the office and iPad for treatment-room charting, in which case Kandji's zero-touch enrollment and deep Apple management make a new hospital's rollout fast. The gap shows up the moment a hospital's front desk runs Windows, whether by history or because the practice management vendor recommends it, since Kandji has no Windows management at all.

A hospital that's fully committed to Apple hardware and confirmed its practice management software runs on Mac without workarounds is a genuinely good fit for Kandji. The risk is assuming that's true without checking, since a lot of veterinary practice management software still leans Windows-first even when a Mac client technically exists.

Veterinary hospitals turn over front-desk and technician staff often, and a group opening or acquiring hospitals adds new locations on top of that. Rippling IT ties device provisioning to the same hire record it uses for payroll, so a new technician's laptop is configured the day they start rather than whenever someone gets to it. For a group with one steady hospital and low turnover, that link matters less; for a group opening a third or fourth location this year, it's a real time saver.

The same link helps on the way out, too. A technician who leaves on bad terms shouldn't still have access to practice management data a week later because nobody remembered to revoke it, and tying that revocation to the termination event in payroll removes the dependency on someone remembering.

An acquired hospital arrives with whatever hardware and habits its previous owner had, and standardizing it on day one rarely goes well. Inventory the acquired hospital's devices separately from your existing fleet first: which are Mac, which are Windows, which are already enrolled in some other management tool. Only then decide whether it joins your existing platform immediately or on a short delay while imaging and lab integrations get tested.

A common mistake at this stage is forcing the acquired hospital onto the group's standard platform before confirming its imaging and lab systems actually work under the new restrictions. Test the integration on one workstation before rolling the change out to the whole hospital, since a failed digital radiography connection on opening week undoes a lot of the acquisition's goodwill with the staff who just joined.

When you acquire a hospital, work through these steps in order:

1. Inventory the acquired hospital's devices separately from your existing fleet, instead of assuming they match your standard.
2. Note which devices are Mac, which are Windows, and which are already enrolled in some other management tool.
3. Mark imaging and lab systems the equipment vendor controls, and hold them out of enrollment until you confirm the vendor's terms.
4. Only then decide which devices move onto your chosen platform.

A group with two or three hospitals often manages devices by having the practice manager handle it between other duties, which works until something breaks at a hospital an hour away. Pricing a dedicated hire against a platform subscription is worth doing honestly: national wage data puts the median salary for a general operations manager, a role frequently stretched to cover this kind of duty at a growing hospital group, at $105,770 a year¹. A platform subscription across several hospitals is very likely cheaper than that hire, but the hire brings judgment a platform doesn't.

Many groups land on a mix: a platform to handle routine provisioning and patching automatically, plus a part-time or shared IT contact who handles the exceptions, like a hospital's imaging integration breaking after an update. Neither option alone covers everything a growing hospital group runs into.