The Implementation Problems Hiding in Your Support Data

The following is a guest article by Steve DeWitt

Everything can look set and you can convince yourself the job is done. The technology is live, people have been trained, support is answering questions, and the dashboard may say everything is being handled on time. That is all good. It still does not mean the implementation actually stuck.

One of the places I would look first is the support data. Not because a customer opened a ticket. Customers are going to open tickets. I care more about what keeps coming back: the same basic questions, repeat complaints, usage that is not where it should be, growing frustration, or nobody inside the customer really stepping up to keep things moving.

What I Would Look For First

A lot of tickets will get my attention, but I would not stop there. I want to know where usage is compared with where we expected it to be, whether the customer has any real internal advocates, and whether we are solving new problems or answering the same ones over and over again.

There is also a relationship piece that is harder to put into a spreadsheet. Are people still interested when you talk with them? Are they trying to get the next training scheduled, or are they dragging their feet? Do they want to expand the rollout, or does every conversation go back to the same complaint? Those things do not tell me exactly what the problem is, but they tell me there may be one.

A Bad Handoff Can Show Up Later

A bad handoff does not always look like some obvious blowup. A lot of times it is smaller than that. Training is delayed, incomplete, or not lined up with what the customer is actually trying to accomplish. Maybe the product is live before the people using it are really ready. Then the effects start showing up later in support calls, usage, delays, and the tone of the relationship.

Training is a good example. You can train somebody and still not really prepare them. If the timing, sequence, or content does not connect to what they are eventually supposed to do with the technology, support can wind up re-answering questions that should have been handled earlier.

I saw a version of this with a large health system I worked with. We had issues early and things did not move the way we wanted. The customer became less enthusiastic, additional training kept getting pushed out, and expansion happened one step at a time instead of building momentum. There was not one magic ticket that told me the implementation was in trouble. It was the whole pattern.

The Number is Not the Whole Story

This is where the numbers can make you feel better than you should. A support team can hit its service levels, close tickets quickly, and still have a bigger implementation problem sitting underneath all of it.

Say the promised callback is an hour and somebody calls back in five minutes. Great. What happened after that? Was the call five minutes or forty-five? Did the customer call again two days later about the same thing? Is it always the same department or the same handful of users? If people still need the vendor for basic things they should be handling on their own, the fast callback is nice, but it is not the whole story.

You also have to define what normal means for that customer. A response-time number can tell you support answered quickly. It cannot tell you whether the customer trusts the product, knows how to use it, wants to expand it, or has built enough internal capability to stop depending on the vendor for every little thing.

A Ticket is a Clue, Not a Verdict

The vendor is not automatically the problem either. Customers change. People leave, priorities move, budgets tighten, goals change, another vendor gets involved, or expectations were unrealistic from the start. Sometimes the product is no longer a fit. Support data can point you toward the issue, but it cannot make that determination by itself.

So I would not see a cluster of tickets and immediately say the implementation failed. I would use it as the reason to dig in. Support, customer success, implementation, sales or account management, and the customer’s internal champion all see different parts of the account. Put those views together and figure out what you actually have: training, workflow, product performance, expectations, ownership, organizational change, or some mix of them.

What I Would Measure

Beyond total ticket volume and response time, I would look at repeat issues, repeat callers, escalations, call length, usage trends, and how often training or rollout steps are getting delayed. I would also look at whether the customer is expanding use of the product or gradually slowing everything down. One isolated number matters less than whether several signals are starting to point the same way.

And I would not ignore the human side because it is not perfectly measurable. Are the people on the account engaged? Is there somebody internally pushing this forward? When you suggest the next step, do they want to do it, or does it become another chore that has to be chased? That should not replace the data, but it helps explain what the data means.

The biggest mistake, to me, is treating support data like a list of problems that got closed. I care more about what is happening to the customer over time. Are they getting more capable and independent, or are we just getting faster at answering the same questions? Those are two very different things.

If the same simple issues keep coming back, usage is behind where it should be, training keeps getting pushed, nobody inside the customer is carrying the ball, and frustration is going up, then closing tickets faster is not the finish line. At that point, you may simply be getting very efficient at servicing a problem that was never actually solved.

About Steve DeWitt

Steve DeWitt works across healthcare commercialization, strategic accounts, implementation, and organizational execution. His writing focuses on adoption, ownership, and the gap between formal support and what organizations actually use in day-to-day work.

The following is a guest article by Steve DeWitt

Everything can look set and you can convince yourself the job is done. The technology is live, people have been trained, support is answering questions, and the dashboard may say everything is being handled on time. That is all good. It still does not mean the implementation actually stuck.

One of the places I would look first is the support data. Not because a customer opened a ticket. Customers are going to open tickets. I care more about what keeps coming back: the same basic questions, repeat complaints, usage that is not where it should be, growing frustration, or nobody inside the customer really stepping up to keep things moving.

What I Would Look For First

A lot of tickets will get my attention, but I would not stop there. I want to know where usage is compared with where we expected it to be, whether the customer has any real internal advocates, and whether we are solving new problems or answering the same ones over and over again.

There is also a relationship piece that is harder to put into a spreadsheet. Are people still interested when you talk with them? Are they trying to get the next training scheduled, or are they dragging their feet? Do they want to expand the rollout, or does every conversation go back to the same complaint? Those things do not tell me exactly what the problem is, but they tell me there may be one.

A Bad Handoff Can Show Up Later

A bad handoff does not always look like some obvious blowup. A lot of times it is smaller than that. Training is delayed, incomplete, or not lined up with what the customer is actually trying to accomplish. Maybe the product is live before the people using it are really ready. Then the effects start showing up later in support calls, usage, delays, and the tone of the relationship.

Training is a good example. You can train somebody and still not really prepare them. If the timing, sequence, or content does not connect to what they are eventually supposed to do with the technology, support can wind up re-answering questions that should have been handled earlier.

I saw a version of this with a large health system I worked with. We had issues early and things did not move the way we wanted. The customer became less enthusiastic, additional training kept getting pushed out, and expansion happened one step at a time instead of building momentum. There was not one magic ticket that told me the implementation was in trouble. It was the whole pattern.

The Number is Not the Whole Story

This is where the numbers can make you feel better than you should. A support team can hit its service levels, close tickets quickly, and still have a bigger implementation problem sitting underneath all of it.

Say the promised callback is an hour and somebody calls back in five minutes. Great. What happened after that? Was the call five minutes or forty-five? Did the customer call again two days later about the same thing? Is it always the same department or the same handful of users? If people still need the vendor for basic things they should be handling on their own, the fast callback is nice, but it is not the whole story.

You also have to define what normal means for that customer. A response-time number can tell you support answered quickly. It cannot tell you whether the customer trusts the product, knows how to use it, wants to expand it, or has built enough internal capability to stop depending on the vendor for every little thing.

A Ticket is a Clue, Not a Verdict

The vendor is not automatically the problem either. Customers change. People leave, priorities move, budgets tighten, goals change, another vendor gets involved, or expectations were unrealistic from the start. Sometimes the product is no longer a fit. Support data can point you toward the issue, but it cannot make that determination by itself.

So I would not see a cluster of tickets and immediately say the implementation failed. I would use it as the reason to dig in. Support, customer success, implementation, sales or account management, and the customer’s internal champion all see different parts of the account. Put those views together and figure out what you actually have: training, workflow, product performance, expectations, ownership, organizational change, or some mix of them.

What I Would Measure

Beyond total ticket volume and response time, I would look at repeat issues, repeat callers, escalations, call length, usage trends, and how often training or rollout steps are getting delayed. I would also look at whether the customer is expanding use of the product or gradually slowing everything down. One isolated number matters less than whether several signals are starting to point the same way.

And I would not ignore the human side because it is not perfectly measurable. Are the people on the account engaged? Is there somebody internally pushing this forward? When you suggest the next step, do they want to do it, or does it become another chore that has to be chased? That should not replace the data, but it helps explain what the data means.

The biggest mistake, to me, is treating support data like a list of problems that got closed. I care more about what is happening to the customer over time. Are they getting more capable and independent, or are we just getting faster at answering the same questions? Those are two very different things.

If the same simple issues keep coming back, usage is behind where it should be, training keeps getting pushed, nobody inside the customer is carrying the ball, and frustration is going up, then closing tickets faster is not the finish line. At that point, you may simply be getting very efficient at servicing a problem that was never actually solved.

About Steve DeWitt

Steve DeWitt works across healthcare commercialization, strategic accounts, implementation, and organizational execution. His writing focuses on adoption, ownership, and the gap between formal support and what organizations actually use in day-to-day work.