The thing was built. Nobody was using it.

Getting a patient onto the portal was two steps, and the two were asynchronous. Somebody reached out. Then, whenever the patient got around to it, which might be that evening or six weeks later, they went to the portal and created a profile. Then somebody had to open the patient records system, find that specific person by name, and link the two profiles together.

That third step is where it died. With close to a hundred thousand registered patients, linking meant searching for each one individually, by name, and there is no version of that a clinic network can staff. Adoption did not stop because anyone decided to stop. It stopped at the point where the manual work exceeded what the people doing it could absorb alongside their real job.

And the cost of not finishing was continuous rather than one-off. Every patient not on the portal telephones reception to book an appointment. They telephone again to reschedule it. They telephone again to cancel it. Each of those calls occupies a receptionist for as long as it takes, at every clinic, every day, for as long as the patient is not on the portal.

This is the pattern worth recognizing, because it is common and it is usually misdiagnosed. The build was fine. The business case was fine. What was missing was the deployment and adoption work, which almost nobody budgets for and which quietly decides whether an investment returns anything at all.

A department that cannot keep up needs its work redesigned. A company in this situation needs something it already owns to actually get used. Those are different problems, they have different first steps, and treating the second as though it were the first is how companies end up buying a second system to fix the adoption of the first one.

1. Reach out and remind, without anyone doing it

   Patients were contacted and then reminded on a rhythm, which removed the first constraint: the network no longer onboarded only as many patients in a week as somebody had hours to contact.

2. Link on registration, automatically

   The step that made this impossible. The moment a patient completed a profile, it was matched to their record and linked without anyone opening the records system or typing a name into a search box. That single change is what turned an unstaffable task into one that does not need staffing at all.

3. Run adoption as work, not as hope

   Progress was tracked weekly against a target rather than reviewed at the end. That is the whole difference between a deployment and a launch.

Portal usage passed fifty percent in seven weeks, close to double where it had been, without a single person being added to do it. Every one of those patients is one who now books, reschedules and cancels without telephoning anybody.

If you have something built that is not being used, the honest first question is not whether to rebuild it. It is what the adoption gap is actually costing you every week it stays open, and whether the work to close it is weeks or months. That is one of the three things a prioritization pass answers.