In Practice | From the inside: what I see, what it means, and why it matters.
Technology might be plug and play, but operations are not.
“We’re just replacing the phones.” Sounds simple enough, doesn’t it? Buy the phones, connect them to Wi-Fi, set up the extensions, and make sure they ring and transfer to the right people. Done.
Except we’re not done. That’s the tip of the iceberg. Most of the work is below the waterline, in the day-to-day operation of the business. And that’s the part that’s easy to miss.
I remember when replacing a phone system was a major undertaking. Years ago, when I was running a medical practice, we covered the conference room walls with giant sticky pages. We mapped call flows, ring sequences, departments, responsibilities, and all the different ways a call might need to move through the practice.
It was tedious work, but it brought the people who understood the operation into the conversation. We weren’t simply deciding how to program the phones. We were deciding how we wanted the practice to handle calls and making sure the new system supported that.
We moved those pages into the lunchroom so everyone could see what was coming. We planned training, and we even scheduled the changeover during a major annual event that sent many locals out of town to escape the crowds and traffic. Business was typically slow that week, which gave us room to make adjustments without disrupting patients.
The launch went remarkably well. Not because the technology was better than what we have today. It wasn’t. But we’d done the thinking before we started making the changes.
Fast-forward to today. You can purchase a cloud-based phone system, work through the setup with a provider, and manage much of the configuration yourself. It’s easier, faster, and often far less expensive. And that’s a good thing.
But there’s a catch. The technology has gotten easier. The operational thinking hasn’t.
I recently watched this play out in a business. Everyone knew it was time for a new phone system. The owner agreed, and a member of the administrative team took responsibility for purchasing and setting it up. This was someone who genuinely wanted to do a good job and, in many respects, did.
The phones worked. Calls rang. Transfers worked. So far, so good. But this wasn’t just a phone system. It could also connect with the software the business used to manage its daily work. Now things got interesting.
First, there was the integration.
Connecting two systems sounds wonderful. Information moves automatically, and people spend less time entering it twice. But what information was actually moving between the systems? Which phone-number field was used to match incoming calls? What happened when someone called from a number the system didn’t recognize?
Was a call record being saved? A transcript? A reference that allowed someone to retrieve the call later? Before deciding how the integration should be used, someone needed to understand what it was doing automatically, what it wasn’t doing, and what the business would need to handle another way.
Those aren’t just setup questions. They’re decisions about how the business wants to work.
Then there were the features nobody had agreed to use.
The business software had a calendar. Someone discovered it and started using it. Nothing wrong with the calendar itself, but the team hadn’t made a shared decision about whether that was the calendar everyone should use. Now people were working from different places, and confusion followed.
A feature can work perfectly well and still cause problems when nobody has agreed on how it fits into the operation.
And then the person who set things up left.
Some knowledge remained within the team about pieces of the configuration, but not the whole picture. Important account information, settings, and decisions hadn’t been documented well enough for someone else to easily take over. The phones were still working, but understanding how everything had been set up, and why, had become a problem of its own.
Here’s what I find especially important about this situation. The person handling the project wasn’t careless. The owner wasn’t ignoring the business. Neither fully understood how many decisions were hiding inside what appeared to be a straightforward assignment.
And that’s exactly why these things happen. The owner didn’t need to know how to configure the system, but the business needed someone asking how the new system would affect the way people worked.
One idea can lead to a hundred decisions. And some of those decisions need to be made before the purchase is even made.
Before choosing a system, what are we trying to improve? Once we choose it, what else will it touch? Who needs to be part of those conversations? What will change for the people doing the work? And how will we document what we’ve done for future reference?
That first decision, what are we trying to improve, will help guide all the others.
Technology might be plug and play, but operations are not.
Planning a technology change?
I’ve put together a simple guide with ten questions worth asking before you get started. Not a technical checklist, just a way to think through what your next change might touch before you plug it in.
Before You Plug It In: 10 Questions to Ask Before Adding or Changing Technology
Leave a Reply