SlothVet

SlothVet is an AI product for veterinary clinics, born inside Wakyma, the veterinary practice-management software where I work. Its premise is simple: give vets back the time that admin and management steal from patient care.

I've been involved since the product's conception in late 2024, shaping it from the first round of research through to the usage instrumentation we run today.

Before designing anything, I scheduled and ran more than ten one-hour interviews with real Wakyma clients, to understand how they actually managed consultations, reputation, and inventory, and where their sharpest friction was.

During the feedback phase I also went into clinics in person, omnidirectional microphone in hand, to test the consultation-notes feature in real appointments, because a voice AI isn't validated in a demo but in the noise of a room with an animal on the table. Three painpoints kept surfacing across every conversation.

SlothVet set out to give that time back by automating the administrative load with AI, without making vets change how they work or switch software.

One finding set the strategy: at that moment, no veterinary practice-management software in Spain had shipped AI tools. So instead of building SlothVet only inside Wakyma, I helped frame it as two products in parallel: one integrated into Wakyma and one standalone, so any clinic, whatever system it already used, could adopt AI without migrating tools.

That decision shaped everything downstream: the standalone product had to earn trust on its own, while the integrated one could lean on the data Wakyma already held. Both shipped — and the standalone is live and growing today, bringing SlothVet's AI to clinics on other practice-management systems. For Wakyma it was also a business bet: being the first vet practice-management software in Spain to ship AI, a differentiator that's hard to copy and a selling point against the competition. The adoption data that follows comes from the Wakyma-integrated product.

The Wakyma-integrated version leaned on its CRM (including animal-history summaries), while standalone SlothVet started lean (consultation recording, reports, and reviews/surveys), with no record management yet.

From there, continuous feedback (a Canny forum, support chat, phone calls, and follow-up interviews with early testers) drove the roadmap: per-user AI permissions inside Wakyma, client and pet records with saved consultations in the standalone product, and delivery-note and invoice upload to speed up inventory management.

Two of those were Human-AI design decisions I owned end to end. I made AI permissions granular by tool and by employee, so each clinic controls exactly who can use which AI feature. And I designed the invoice/delivery-note upload so it never writes to inventory blindly: when the AI isn't confident it read a document correctly, or detects a duplicate of one already uploaded, I have it surface that item with a ‘Review’ flag instead of quietly committing it — keeping a human in the loop before anything reaches the inventory.

Those administrative and inventory tools were thriving (the data above). The feature we'd bet on as the flagship, though, told a different story: automatic consultation notes sat at just 45% among paying clinics, below the very tools it was meant to headline. Fully available there and still trailing the admin features, that 45% was the real mystery to solve.

The team's first hypothesis was hardware, and an aggressive offer was already on the table: a year of discount plus a free omnidirectional microphone. I pushed back. Spending the budget there assumed we already knew the cause, and nothing I'd heard from vets supported it. So instead of guessing, I made the call to instrument the problem, with two mechanisms designed to tell the competing explanations apart: a literal transcript of each consultation, which shows whether the audio came in clean or the AI misheard it, and a per-consultation survey that captures, in the vet's own words, what failed when the notes still weren't useful. Each result points to a different fix: bad audio would finally justify the microphone offer, with evidence behind it; clean audio with wrong notes points at the model; accurate notes left unused points at the workflow. Both mechanisms are in implementation as of June 2026. The result I'll stand behind isn't a recovered adoption number yet, it's the decision itself: we didn't burn budget on an unverified fix, we built the experiment that finds the cause. In a product still finding its footing, choosing to learn over guessing is the outcome.

The most useful lesson was to distrust the assumed 'star feature': a feature being used less than expected doesn't mean it's redundant. It means you don't understand the friction yet. Designing for AI adoption turned out to be less about improving the output and more about building verification and trust around it.