This is the fourth post in a series about improving human-bot relations in customer service. See my page to get caught up.

Absent a bug in the system, software programs have a hard time getting distracted. An algorithm can repeat the same rote task millions of times without so much as a glance at the football scores. More than this, programs stick to their priorities. You won’t see second-guessing, quid pro quo deals, or personal favors.

Humans, on the other hand, we are notorious for being both distracted and off-task. At the individual level, we should accept this as a trade-off for the empathy, nuance, and multi-layered problem-solving that humans bring. For the toughest customer service work, I’ll take an empowered, multi-tasking problem-solver with rich and varied interests over an automaton any day of the week.

But at a group level, distraction and reprioritization start to become problems. That is because these glitches are not additive in groups, but multiplicative. In a meeting, one person can easily steer an entire team into a lengthy discussion about a trivial matter. One team can influence the whole company. This is so common that it has a technical term, Parkinson’s Law of Triviality, and a popular moniker, bikeshedding. (Bikeshedding refers to a fictional team that spent more time planning the employee bike shed than the nuclear power plant they were tasked to design. A corollary of bikeshedding is the goldfish phenomenon where, like a goldfish that grows to fit its bowl, any task or meeting will consume the amount of time it is allowed.) [1]

In Customer Service, if you find yourself tracking 100 metrics while your CSAT continues to slip, researching best practices in outsourcing for months-on-end while your backlog grows insurmountable, or wrestling endlessly with knowledge base technology choices while your customers cannot self-serve, you might have a bikeshedding problem.

What if you were to address this problem like a software architect? You would be forced to decide your priorities and encode them into the fabric of your execution systems. For example, you could create a balanced scorecard of KPIs, ranked in order of importance, as an expression of your priorities. Then, orient and incentivize your network to take actions — automated where feasible — that improve your scorecard results. (If you like this idea, stay tuned for a future post with more details.) Or, you could follow Google’s lead and encode your priorities into an Objectives and Key Results (OKRs) rubric. [2]