The Seventh Tab Problem
The rollout worked. The training happened. The tickets stopped. None of that tells you whether anyone's actually using it.
8 min read | IT Managers & Directors | IT Management & User Adoption
Every rollout eventually hits a quiet patch. The access issues got sorted out in week one. The FAQ answered the obvious questions. The tickets slowed to a trickle. Somewhere around week three, it looks like a win.
It might be. Or it might mean something else entirely: people stopped asking questions because they stopped using the tool, not because they mastered it. A clean rollout and a quiet one look identical from the help desk's side of the glass, and the only way to tell them apart is to know what you're actually looking at.
This week's podcast episode with Nicolas Fry, founder of TurboDocx, gets at exactly this from the vendor side. His perspective on why software gets adopted or quietly dropped applies directly to what a support queue can and can't tell you about the technology you just rolled out.
|
Why "It Works" and "People Use It" Are Different Claims
Fry's framing is that most people's entire working life narrows down to a handful of tools, what he calls the five tabs. Anything that doesn't earn a permanent spot in that short list doesn't get used, no matter how capable it is, and when it doesn't make the cut, people don't complain about it. They just route around it.
That's a sharper way of saying what a lot of IT managers already suspect but rarely get to confirm: a tool can clear every technical bar, pass every test, train every end user, and still lose to habit. Nobody files a ticket to say they went back to the old spreadsheet. They just quietly did it, and quietly built a new, unofficial flow around the gap.
54%of provisioned software licenses are actually used at the average organization, according to Zylo. That leaves nearly half of provisioned licenses potentially underutilized, representing an opportunity to reduce unnecessary software spending. | 1 in 7employees have outright refused to use a workplace tool, according to Yooz's 2025 survey. Another 39% describe themselves as reluctant adopters. |
Neither of those numbers shows up as a support ticket. That's the trap. A technology rollout can hit every milestone on the project plan and still fail the one test that actually matters: whether employees are using the software.
And when that happens, the cost goes beyond unused licenses. The organization may continue paying for the manual processes, inefficiencies, and workarounds the new technology was supposed to eliminate.
What Support Patterns Actually Reveal
The good news is that adoption failure isn't necessarily invisible. The ticket queue can hold a useful signal. It's just not always in the volume. It's in the shape.
People who've genuinely adopted a new tool may generate a recognizable pattern of tickets early on: configuration questions, "how do I" requests, and edge cases that only show up with real use. People who've quietly routed around a tool may generate almost nothing, because there's nothing to troubleshoot in a tool nobody's touching.
There's a third pattern worth watching too: tickets that reference the old system by name, months after it was supposed to be retired. "Can you pull this from the old portal?" "I still have the spreadsheet, can I just send that?"
Each one is small. Together, they suggest the new tool may have become exactly what Fry described: something people route around rather than route through.
None of these patterns proves adoption or avoidance on its own. But they give IT a reason to investigate rather than assume a quiet queue means a successful rollout.
What To Do With That
None of this means chasing down every quiet user with a survey. It means changing what you check for, and when.
1. Watch the first month's ticket shape, not just its size
In the weeks right after a rollout, a healthy pattern may include a spread of configuration and edge-case questions across different end users, not just a handful of repeat callers. Who's asking matters as much as what they're asking.
Five different people hitting five different edge cases suggests a tool is getting real, varied use. One person filing five tickets while the rest of the team stays silent is a much narrower signal, and it's easy to mistake the two for the same thing if you're only counting total tickets.
If ticket activity drops to near zero immediately after launch, that's worth a closer look before you call it a smooth rollout.
If you have access to usage dashboards or login data, compare them with what you're seeing in the queue. If you don't, ticket patterns can still help identify where to investigate, but they shouldn't be treated as proof of adoption.
2. Listen for the old system's name
Technicians already hear it when someone asks for something "the old way," wants a file emailed instead of pulled from the new system, or asks for an export so they can keep working in the format they're used to.
None of that gets logged as a complaint, so none of it shows up in a ticket report unless someone decides to capture it.
Give those mentions somewhere to go, whether it's a shared tag or a quick note at the end of a ticket, instead of letting them pass as one-off asides. A handful of those notes over a month can reveal a pattern that a traditional ticket dashboard might miss, and it costs a technician only seconds to log.
3. Make the new tool the easiest flow, not just the approved one
Fry's advice to vendors applies just as well inside a company rolling out a tool to its own teams.
For IT, that means the fix for quiet avoidance isn't necessarily more training. It's often removing the extra step.
If the new system requires a login the old workflow didn't, or a format change people have to think about, that friction is exactly the habit Fry's talking about working against you.
A tool that's merely as good as the old habit may still lose to it because the old habit has no relearning cost.
Shrinking that gap, whether it's a bookmark instead of a typed URL, a default view that matches what people already expect, or one fewer click to something they do fifty times a day, can do more for adoption than another reminder email.
4. Once you've confirmed it, don't just retrain harder
Say the signals line up: a handful of users, questions that never got past the basics, and the old system's name still showing up in tickets three months in.
The instinct is often to schedule another training session. But if the problem is the gap between the new tool and people's existing habits, more training won't necessarily close it.
A more useful next move is a short, direct conversation with a few of the people who quietly opted out. Ask what they're actually doing instead and why.
That conversation may surface a specific friction point, such as a missing integration, an extra login, or a format mismatch, rather than a vague sense that the tool is "hard to use."
From there, you have three options: fix the friction if it's fixable, formally retire the workaround if the new tool meets the need, or raise the issue with whoever made the purchasing decision if the software itself isn't going to close the gap.
All three are more productive than automatically scheduling another training session.
The Signal Decoder
A technically successful rollout and a genuinely adopted one can look exactly the same from inside the help desk for the first few weeks. The difference shows up later, in whether the questions evolve, whether the old system's name fades out of tickets, and whether the people who never filed a complaint were actually fine or simply working around the new technology.
As we explored in Go-Live Isn't the Finish Line, the project plan calls a rollout done the moment it ships. But your ticket queue can keep revealing adoption issues long after that, if you know what to listen for. And as we discussed in The Purchase Price Isn't the Whole Price, getting support involved before the purchase can help identify potential friction before it becomes an adoption problem.
A successful deployment gets the technology into the organization. Successful adoption gets it into the workflow.
About the Author
Michelle Burnham has worked in and around the technology industry for nearly a decade; collaborating with IT support teams and contributing to technical documentation, service-oriented content, and operational communications. With a background in editing, formatting, and visual design, she specializes in translating complex ideas into clear, engaging content. In addition to her freelance creative work, she serves as a contract graphic designer, copywriter, and video editor for Helpt.
The rollout worked. The training happened. The tickets stopped. None of that tells you whether anyone's actually using it.
8 min read | IT Managers & Directors | IT Management & User Adoption
Every rollout eventually hits a quiet patch. The access issues got sorted out in week one. The FAQ answered the obvious questions. The tickets slowed to a trickle. Somewhere around week three, it looks like a win.
It might be. Or it might mean something else entirely: people stopped asking questions because they stopped using the tool, not because they mastered it. A clean rollout and a quiet one look identical from the help desk's side of the glass, and the only way to tell them apart is to know what you're actually looking at.
This week's podcast episode with Nicolas Fry, founder of TurboDocx, gets at exactly this from the vendor side. His perspective on why software gets adopted or quietly dropped applies directly to what a support queue can and can't tell you about the technology you just rolled out.
|
Why "It Works" and "People Use It" Are Different Claims
Fry's framing is that most people's entire working life narrows down to a handful of tools, what he calls the five tabs. Anything that doesn't earn a permanent spot in that short list doesn't get used, no matter how capable it is, and when it doesn't make the cut, people don't complain about it. They just route around it.
That's a sharper way of saying what a lot of IT managers already suspect but rarely get to confirm: a tool can clear every technical bar, pass every test, train every end user, and still lose to habit. Nobody files a ticket to say they went back to the old spreadsheet. They just quietly did it, and quietly built a new, unofficial flow around the gap.
54%of provisioned software licenses are actually used at the average organization, according to Zylo. That leaves nearly half of provisioned licenses potentially underutilized, representing an opportunity to reduce unnecessary software spending. | 1 in 7employees have outright refused to use a workplace tool, according to Yooz's 2025 survey. Another 39% describe themselves as reluctant adopters. |
Neither of those numbers shows up as a support ticket. That's the trap. A technology rollout can hit every milestone on the project plan and still fail the one test that actually matters: whether employees are using the software.
And when that happens, the cost goes beyond unused licenses. The organization may continue paying for the manual processes, inefficiencies, and workarounds the new technology was supposed to eliminate.
What Support Patterns Actually Reveal
The good news is that adoption failure isn't necessarily invisible. The ticket queue can hold a useful signal. It's just not always in the volume. It's in the shape.
People who've genuinely adopted a new tool may generate a recognizable pattern of tickets early on: configuration questions, "how do I" requests, and edge cases that only show up with real use. People who've quietly routed around a tool may generate almost nothing, because there's nothing to troubleshoot in a tool nobody's touching.
There's a third pattern worth watching too: tickets that reference the old system by name, months after it was supposed to be retired. "Can you pull this from the old portal?" "I still have the spreadsheet, can I just send that?"
Each one is small. Together, they suggest the new tool may have become exactly what Fry described: something people route around rather than route through.
None of these patterns proves adoption or avoidance on its own. But they give IT a reason to investigate rather than assume a quiet queue means a successful rollout.
What To Do With That
None of this means chasing down every quiet user with a survey. It means changing what you check for, and when.
1. Watch the first month's ticket shape, not just its size
In the weeks right after a rollout, a healthy pattern may include a spread of configuration and edge-case questions across different end users, not just a handful of repeat callers. Who's asking matters as much as what they're asking.
Five different people hitting five different edge cases suggests a tool is getting real, varied use. One person filing five tickets while the rest of the team stays silent is a much narrower signal, and it's easy to mistake the two for the same thing if you're only counting total tickets.
If ticket activity drops to near zero immediately after launch, that's worth a closer look before you call it a smooth rollout.
If you have access to usage dashboards or login data, compare them with what you're seeing in the queue. If you don't, ticket patterns can still help identify where to investigate, but they shouldn't be treated as proof of adoption.
2. Listen for the old system's name
Technicians already hear it when someone asks for something "the old way," wants a file emailed instead of pulled from the new system, or asks for an export so they can keep working in the format they're used to.
None of that gets logged as a complaint, so none of it shows up in a ticket report unless someone decides to capture it.
Give those mentions somewhere to go, whether it's a shared tag or a quick note at the end of a ticket, instead of letting them pass as one-off asides. A handful of those notes over a month can reveal a pattern that a traditional ticket dashboard might miss, and it costs a technician only seconds to log.
3. Make the new tool the easiest flow, not just the approved one
Fry's advice to vendors applies just as well inside a company rolling out a tool to its own teams.
For IT, that means the fix for quiet avoidance isn't necessarily more training. It's often removing the extra step.
If the new system requires a login the old workflow didn't, or a format change people have to think about, that friction is exactly the habit Fry's talking about working against you.
A tool that's merely as good as the old habit may still lose to it because the old habit has no relearning cost.
Shrinking that gap, whether it's a bookmark instead of a typed URL, a default view that matches what people already expect, or one fewer click to something they do fifty times a day, can do more for adoption than another reminder email.
4. Once you've confirmed it, don't just retrain harder
Say the signals line up: a handful of users, questions that never got past the basics, and the old system's name still showing up in tickets three months in.
The instinct is often to schedule another training session. But if the problem is the gap between the new tool and people's existing habits, more training won't necessarily close it.
A more useful next move is a short, direct conversation with a few of the people who quietly opted out. Ask what they're actually doing instead and why.
That conversation may surface a specific friction point, such as a missing integration, an extra login, or a format mismatch, rather than a vague sense that the tool is "hard to use."
From there, you have three options: fix the friction if it's fixable, formally retire the workaround if the new tool meets the need, or raise the issue with whoever made the purchasing decision if the software itself isn't going to close the gap.
All three are more productive than automatically scheduling another training session.
The Signal Decoder
A technically successful rollout and a genuinely adopted one can look exactly the same from inside the help desk for the first few weeks. The difference shows up later, in whether the questions evolve, whether the old system's name fades out of tickets, and whether the people who never filed a complaint were actually fine or simply working around the new technology.
As we explored in Go-Live Isn't the Finish Line, the project plan calls a rollout done the moment it ships. But your ticket queue can keep revealing adoption issues long after that, if you know what to listen for. And as we discussed in The Purchase Price Isn't the Whole Price, getting support involved before the purchase can help identify potential friction before it becomes an adoption problem.
A successful deployment gets the technology into the organization. Successful adoption gets it into the workflow.
About the Author
Michelle Burnham has worked in and around the technology industry for nearly a decade; collaborating with IT support teams and contributing to technical documentation, service-oriented content, and operational communications. With a background in editing, formatting, and visual design, she specializes in translating complex ideas into clear, engaging content. In addition to her freelance creative work, she serves as a contract graphic designer, copywriter, and video editor for Helpt.
Stop Answering Calls.
Start Driving Growth.
Let Helpt's US-based technicians handle your support calls 24x7 while your team focuses on what matters most.
Stop Answering Calls.
Start Driving Growth.
Let Helpt's US-based technicians handle your support calls 24x7 while your team focuses on what matters most.
Stop Answering Calls.
Start Driving Growth.
Let Helpt's US-based technicians handle your support calls 24x7 while your team focuses on what matters most.
©2026 Helpt, a part of PAG Technology Inc. All Rights Reserved.