There's a particular kind of silence that happens in Slack when someone links to the new self-service portal. Not the silence of people clicking through and exploring. The silence of people reading the message, understanding what's being asked of them, and quietly deciding to do the thing the old way instead.
This happens everywhere. The password reset tool that exists but nobody knows about because everyone just submits a ticket. The knowledge base that was supposed to handle 80 percent of common questions but somehow hasn't reduced support volume at all. The expense reporting system that's technically easier than the previous one but somehow takes people longer to figure out.
What's interesting isn't that these tools fail. It's what the failure reveals about the people who built them.
Someone decided that a self-service portal was the right solution to whatever problem they were trying to solve. That someone probably had a meeting about it, maybe saw a demo from a vendor, definitely had some conviction about the approach. They weren't wrong to think self-service could help. The instinct was sound. But somewhere between the decision and the launch, something got lost.
Most likely, it was this: the people building the tool didn't actually use the process they were trying to improve. Or if they did, they understood it in the abstract way that builders understand their own creations, not the sticky, messy way that actual humans experience it under deadline pressure with seventeen things already demanding their attention.
So the portal got built for how people think about the problem, not for how people actually live with it. It's organized in a way that makes sense on a flowchart. The buttons are labeled with terminology from the process documentation. The happy path works perfectly. But the moment someone encounters a situation that's slightly off-nominal, the tool becomes a puzzle to solve before they can solve their actual problem.
At that point, the math shifts in their head. Submitting a ticket to someone who knows what they're doing starts to look like the faster option. They choose it. Other people watch them choose it and make the same calculation. Pretty soon the tool is abandoned, the support tickets actually increase, and someone in a meeting wonders why the investment didn't pay off.
The thing that's hard to say in those meetings is this: it didn't work because the people building it didn't know what they were building for. Not in their heads. In their hands.
There's a difference between understanding a process and moving through a process. Between reading someone's complaint about how clunky something is and actually feeling that clunkiness yourself when you're in a hurry and stressed. Between designing for what should happen and designing for what actually happens in the corner cases where people live.
The self-service portals that do get used share something. Someone building them actually had to use them. Or someone building them watched actual people use them, over and over, and paid attention to where they hesitated or where they gave up. Not watching a test scenario. Watching the real thing, messy and impatient and human.
That costs more in time. It's slower to build. It doesn't look as clean on a presentation slide. But it works because it was built by someone who understood that a tool exists in the space between an ideal process and a person trying to get through their day.