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.) 
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.