Krishna
Founder, ShylCare
I'll tell you the fastest way to tank a hospital software implementation: train all 40 staff members in a conference room on a Saturday, go live on Monday, and expect everything to work.
By Wednesday, half the staff will have gone back to paper registers. By Friday, the billing clerk will have figured out that if she enters data in the old system "just for now," nobody stops her. By the end of the month, you're running two parallel systems — the new software that nobody uses and the old process that everyone quietly reverted to.
I've seen this happen at least a dozen times. Here's why, and what to do instead.
The standard approach: vendor comes in, sets up a projector, walks through every screen for four hours, hands out a printed manual, and leaves.
The problem is that human beings don't learn software by watching someone else use it. They learn by doing. And the gap between a Saturday training session and Monday go-live is long enough to forget every click sequence they saw.
Add to this that hospital staff are not a homogeneous group. Your 25-year-old receptionist who grew up with smartphones will pick up any interface in ten minutes. Your 55-year-old senior nurse who's been writing in registers for three decades won't — and she shouldn't be expected to. Training them in the same room at the same pace helps neither.
A hospital has departments: OPD reception, billing, pharmacy, lab, radiology, nursing stations, doctor consultation rooms. Each department uses a different part of the software with different workflows.
When you train everyone together, the pharmacist sits through 45 minutes of OPD registration workflows she'll never use. The billing clerk endures a pharmacy dispensing demo that has nothing to do with his job. Everyone's bored by the parts that aren't relevant and overwhelmed by the parts that are.
And here's the hidden problem: when every department goes live simultaneously, every department has problems simultaneously. Your support capacity is spread across fifteen fires at once. Nobody gets proper attention. Frustration builds fast.
Before any training happens, identify one person in each department who is relatively comfortable with technology, has the respect of their colleagues, and is willing to learn first. This is your department champion.
Train the champions first. Not in a classroom — sit with them one-on-one at their actual workstation, with real patient data (or realistic test data), and walk through their specific daily workflows. Let them make mistakes. Let them ask questions. Spend two hours with each champion over two days.
When their department goes live, the champion becomes the first line of support. Their colleagues ask them, not the vendor. This works because people are more comfortable asking a colleague than calling a helpline, and the champion understands the department's specific quirks ("we always do this differently on Tuesdays because Dr. Reddy's clinic hours change").
Don't switch everything at once. Sequence it:
Week 1: Billing and Registration. This is the most critical workflow — patients need bills, and the billing desk is the one place where you can't say "we'll enter it later." Once billing is digital, there's revenue data flowing in immediately. That creates momentum.
Week 2: OPD Consultation. Once registration is working smoothly, bring OPD doctors online. Their workflow is simpler — view patient, write notes, generate prescription. Start with one or two doctors who are willing.
Week 3: Pharmacy Dispensing. Now the prescription flows from OPD to pharmacy digitally. The pharmacist sees what was prescribed, dispenses, and bills from the same system. The connection between OPD and pharmacy starts generating useful data.
Week 4: Lab and Radiology. Orders flow from OPD/IPD to the lab. Results get entered into the system and are visible to the doctor. The loop closes.
Each week, only one department is adjusting to a new process. Your support bandwidth is focused. Problems are contained.
The temptation is to run paper and software side by side "until everyone is comfortable." Don't extend this beyond one week.
Here's why: if parallel running goes on for two weeks or more, the paper system becomes the real system and the software becomes the burden. Staff will enter data in software reluctantly, knowing that the paper register is the "real" record. They'll cut corners in software because "it's also in the register." Data quality will be terrible.
One week of parallel running. After that, the paper register closes. Yes, it's uncomfortable. Yes, the first few days after cutting paper will be slower. That's normal. It's also the only way the new system becomes the real system.
Set up a WhatsApp group with your department champions and the software support team. When the billing clerk doesn't know how to apply a discount or the pharmacist can't find where to enter a batch number, they send a message and get an answer in minutes.
This sounds informal, but it works dramatically better than a support ticket system or a phone helpline for the first month. Hospital staff are already on WhatsApp all day. The barrier to asking for help is near zero. And the answers are visible to everyone in the group — so when one person asks "how do I do a refund?", everyone else who had the same question sees the answer.
After the first month, move to a more structured support process. But for the critical adoption period, low-friction support matters more than process.
Let me be honest about something: the biggest resistance to new software usually comes from senior staff. This isn't because they're technologically incapable — it's because they've built their workflows over decades and a new system implicitly says "your way was wrong."
It wasn't wrong. It worked. The new system is about handling growing volume, reducing errors, and making information accessible — not about replacing anyone's competence.
Have this conversation directly with senior staff before go-live. Acknowledge their experience. Explain that the system is a tool that supports what they already know, not a replacement for it. And make sure the software respects their workflow — if a nurse has always recorded vitals in a specific order, the software should let her do it in that order too.
Resistance that's addressed respectfully tends to dissolve within two weeks of actual use. Resistance that's dismissed or overridden festers for months.
A successful software rollout doesn't look like zero complaints. It looks like complaints that get resolved, champions who feel ownership, and a clear point — usually around week three — where staff start saying "can the software also do X?" instead of "why do I have to use this?"
When they start asking for more features, you've won.
We've built these workflows into ShylCare so you don't have to figure them out alone. See how it works.
We'll walk through your actual workflows — no generic demo, no slide deck.