CRM and Customer Service – Dump the “Rule Zero” Fallacy
I had a conversation last week with one of our support reps that demonstrated with perfect clarity what I call the “Rule Zero Fallacy.”
If you’re a board game or card game enthusiast, inevitably you’ve run across a rule in a game somewhere that you simply didn’t like. And whether it’s pinochle, Rook, Ticket to Ride, or the Settlers of Catan, players usually create a replacement rule, or modify it to better suit their tastes. In some circles this type of “house ruling” is called “Rule Zero,” meaning, “No rule is ever broken because I can fix it.”
The problem is, “Rule Zero” is a fallacy, a contradiction in terms. The fact that you were willing to take the time to fix it yourself (and are generally satisfied with the result) doesn’t change the fact that it needed fixing to begin with.
But back to our real point:
A support agent came to me last week about a client who wanted to access a feature in one of our systems. Due to an admittedly poor interface design for this particular feature, getting access to it was problematic. It took navigating through a number of screens, hunting through the right links, and inputting some user-defined data.
The support rep said, “Client X really likes this feature, but hates having to navigate to it all the time. Can we create a shortcut for this?”
So we brainstormed for a minute, came up with a quick fix for it, and gave it to the client.
But to my discredit, I didn’t follow up. I didn’t check to see if the rep had put the problem in front of one of our developers, or the project manager. Didn’t ensure that the problem was going to be solved universally, and not just for this one client.
I had subconsciously invoked the “Rule Zero” fallacy—”I solved the problem for them, so there really wasn’t one to begin with.”
The Rule Zero Fallacy is fine for board games.
In business it’s deadly.
It cripples customer service initiatives, frustrates clients, and costs revenue.
If we’re repeatedly having to solve the same problem, having customer service “fix” it is certainly one way to deal with it—but clearly the real issue lies somewhere else in the process.
Even seemingly small issues can add up. Just because something is a “10 minute fix” for one client doesn’t mean it isn’t critical, or costing money. How much time and payroll gets lost on both ends of the client / vendor spectrum over seemingly simple “10 minute” fixes? Fixes we simply shrug our shoulders about because “If I fixed it, it wasn’t a problem”?