Since 2024, I've led end-to-end implementation of laboratory automation and healthcare technology across hospitals and clinical labs nationwide — deploying and integrating systems like Copan's WASP, WaspLab, UniVerse, and URIVerse. Every rollout follows the same eight-phase arc, adapted to the lab in front of me.
Every implementation starts with the same question: does everyone understand what the other needs? Locking down hardware, space, and workflow requirements before an instrument ships is what separates a smooth install from a shaky one — and it almost always comes down to communication, not technical surprises.
A single rollout can pull in the lab director, lab manager, IT, sales, and field service engineering — each with different priorities. The friction point that comes up most often is security, particularly around remote connectivity. The job is knowing what can move forward now versus what needs more alignment, rather than letting one open question stall the whole project.
The most common thing I find isn't a broken process — it's a good tool the lab doesn't know exists yet. Before touching the automation itself, we map what happens upstream and downstream of it, because an instrument that isn't integrated into the rest of the workflow doesn't actually save anyone time.
Installation happens in two distinct phases: field engineers handle the hardware and mechanical setup, then we take over for workflow configuration, LIS integration, and testing — approaching everything from a clinical perspective rather than a mechanical one. An engineer confirms a sample transferred; we confirm it transferred with the right prep steps, the right volume, and the right label on it.
Training format scales with the system — a few hours for the simpler platforms, multiple sessions across weeks for the more complex ones. Every session is built around hands-on practice over theory, and closes with a quiz and a feedback survey — training isn't done until we know it landed.
This is the one phase where we deliberately step back. Once staff are trained, validation is handed off entirely to the lab to run independently — partly to avoid any conflict of interest, partly because ownership at this stage is what actually builds confidence in the system.
Go-live support means being on-site, mostly hands-off, and stepping in only when needed — letting staff work the system as they normally would and using real moments of friction as teaching opportunities. By the end, the goal isn't just competence, it's confidence handling whatever comes up in the first weeks.
Support doesn't end at go-live. Depending on the account, that might mean weekly check-in calls or occasional touchpoints, but every support ticket routes directly to us — and resolving it might mean pulling in field engineering or the manufacturer, whatever gets the lab back up fastest.
This page is deliberately the outline, not the transcript — I'm always happy to go deeper on any phase in conversation.
Get in Touch