The request sounded clear: we need scheduling software.
Customers should be able to book a time. The team should see who is available. Reminders should go out without another manual step.
The obvious response would have been a shortlist. Three products, a comparison, a recommendation.
The more useful question was simpler: why add another tool?
The capability was already there
The company already used Microsoft 365. The booking capability it needed was part of the existing setup. It had never been configured around the way the work actually ran.
No new system was introduced. No additional subscription. No second set of accounts. No new place for the same data.
Instead, the work was made explicit. Which appointments should be offered? Who can be booked? Which details are necessary? What has to happen after a booking? Once those questions were settled, the existing capability could be configured and handed over with a short guide.
Sometimes the best software decision is not to buy more software.
Available does not mean used
A company can own more capability than it can see. Modules sit untouched. Two tools perform the same task. A new need can start a new search, even when the answer is already in the room.
That is not only a procurement problem. It is a visibility problem.
What is there becomes normal. So does what is missing. And so does the capability nobody remembers they already have.
Use what is already there
Software decisions usually compare three paths: buy, build, or replace.
One path is often overlooked: make better use of what is already there.
That is not an automatic answer. An existing feature may be too limited, too rigid, or wrong for the data involved. The point is to examine the work before naming the product.
What has to happen? Who decides? Which data is needed? Which exception must remain possible? What should the company be able to control later without the provider?
Only then can you see whether to use, simplify, connect, remove, or build.
The result
In this case, the answer was small. An existing capability, configured around the work, documented clearly, and handed over.
We built nothing new.
That was exactly the point.
Patrick Thole, Disruption Dynamics, Zürich
disruption-dynamics.ch