Tribal Belief, Knowledge Fog, and Other Process Sins

During a now-famous presser in 2002, Donald Rumsfeld launched into a monologue about things we know. In summary and only slightly paraphrasing;

· There are known knowns, things we know we know. 

· There are known unknowns; that is to say, we know there are some things we do not know.

· There are unknown unknowns; the ones we don't know we don't know.

Much ridiculed at the time, the words have transcended into a useful taxonomy for thinking about process improvement, automation, and artificial intelligence. In the business of service delivery, we 'know' many things. Some of it is a verifiable fact, and some of it is tribal belief. 

It seems that whenever two or more of us gather for any amount of time, a common bond of belief magically forms. Those beliefs can be based on thoroughly vetted facts, half-truths, or pure he-said/she-said boo-she. Do you know the basis for the things you know?

Tribal belief has a way of becoming a living thing over time, ever-evolving to suit the current circumstances and expectations. Yes, expectations form a belief.

Truths and tribal beliefs are modulated by conclusion bias. Henry Thoreau said, "Many an object is not seen, though it falls within the range of our visual ray, because it does not come within the range of our intellectual ray. So, in the larger sense, we humans only see the world that we look for". 

Knowing something is a slippery slope of biases, anecdotes, and other big-fat-liar-face 'truths’. Ironically, the longer you 'know' something, the less correct you probably are. 

In the customer service and delivery process world, this is a huge problem. It is a truism that what you 'know' about your workflow is probably a mixed bag of 'truths.' If you are contemplating digital transformation (and you’d better), any attempt to leverage Robotic Process Automation (RPA) or Artificial Intelligence technologies will demand you 'know' all possible about your workflow. For example, here is a quickie list of things that should be known knowns:

The essential transactional time & motion analytics of your process 

· How many transactions are you doing? 

· Do you have enough workforce in place to meet the workload? 

· How long does it take to complete each transaction? 

· What is your fall-out or rework rate?

· What does your process unit cost look like over time?

Or how about stuff you had better know about your customers like:

· Their phone numbers?

· Their account number and service address?

· What issue are they having?

· Was the customer's service just installed?

· What is their service history?

· Has the client's usage pattern changed recently?

Regarding your service platform or network:

· Where precisely are your platform assets?

· Are they working?

· Are they degraded?

· Was there a recent hardware or software change?

· Is the usage pattern within statistical norms?

Regarding your workforce:

· Where is your workforce?

· What is the workforce doing?

· Are their skills current?

· Are their tools working?

· Is your valuable team doing low or high-value work?

· Do you have a mechanism to attach value to the work?

Things you know you don't know.

· Anything from above that you don't know (burst into flames to fix that NOW!)

· What is going to happen tomorrow or an hour from now?

· What is the competition about to do?

· Changing customer and market expectations?

The scary list is the things you don't know you don't know. I know this is the stuff that should haunt your internal fact-checker.

· What are my customers doing that I don't know?

· What is my process doing that I don't know?

· What is my workforce doing that I don't know?

· What are my systems and tools doing that I don't know?

· What does my boss think about my process stewardship that I don't know?

Knowing what you know and don't know is an exercise in intellectual honesty, testing, validation, and time. Any given piece of knowledge is a depreciating asset that has a shelf life, after which it slips from operational relevance into the realm of history. Real-time knowledge is actionable. Historical knowledge is far less so.

Situational awareness

I have always found it useful to imagine the process as an automobile moving through space and time. Knowing that I was at a given highway intersection on a particular day and time last month is historically interesting. Knowing I am there at this second is operationally vital – especially given the big truck crossing in front of me. Situational awareness is the essence of the autonomous driving challenge.

When I talk about knowing things about your process, I am not talking about some blended average of all the stuff that happened last month. That kind of lagging post-facto information is not helpful. It is situational fog and is anti-matter for automation or any AI attempts.

Known things about a process have a temporal relevance to consider. What the process did last year is helpful only at the macro level. Last month is slightly better. Yesterday is good. Ten minutes ago, is better. Real-time is best.

Only when the time relevance of data is high can advanced concepts like AI be leveraged. Let's unpack an example;

•   You know a given client is experiencing packet errors right now. Source – empirical network alarm data that you spent a lot of money building 
•   You know the client's phone number. Source – Your CRM platform that you spent a lot of money building
• You know that the client number is now queued into your customer service call center. Source – telemetry from the ACD that you spent a lot of money building

Moment of truth!  Do you take:

Door number 1 - Answer the call with un-integrated bliss and ask the client to tell you who they are and why they are calling? Which you already know.

Door number 2 -Answer with, “Hi Mrs. Leadbetter. I see you are having service issues, and we are taking (fill-in-the-blank) steps to resolve…”

Door number 3- Or better yet, you don't wait for the incoming call. You use the known knowns in your possession to predict that: Mrs. Leadbetter is having a service issue and you take preemptive steps to resolve the issue then notify her via her preferred means of communication

If you choose door number 3, you accomplish this with simple automation based on Robotic Process Automation (RPA). The RPA bot is, in a sense, a triage agent that has one job. It points its unblinking eye at Mrs. Leadbetter's service watching for degradation 24x7. When the rules for defining degraded service (you established based on best practices and testing experimentation), it opens a trouble ticket. The new ticket is then handed to another RPA bot, which queries your CRM application and matches the CPE MAC address with the client info and places that into the ticket. So far, these two bots have consumed milliseconds of time and fractions of a penny. 

These two automation actions get us to the point we would be facing if we waited for the customer to call. One required millisecond and fractions of a cent, and the other needed the client to register the issue, become annoyed enough to call, and consumed a call center rep and resources to answer the call. The latter is far more expensive. 

The implications are pretty obvious. The NPV of a dollar spent automating this simple little scenario is a profound improvement over the NPV of the customer dissonant call center path. The latter is spent over and over ad nauseam. It is cheaper, faster, and better.

Let's look through a slightly different lens. In my opinion, there are issues of fiduciary responsibility here – 

•   Customers - They put their trust in you to meet the service commitments. Those commitments did not include stealing their time to monitor your service. It is a service sin to expect your customers to do so in my humble opinion.
•   Shareholders – If you have invested capital into systems and tools to institutionalize information about your customers (i.e., CRM) or services (NOC or other alarm-based OSS platforms), you are obligated to leverage that information as fully as possible. Customer information is a known known. Not using that information is a fiduciary sin. 
•   Employees – People like to do exciting and challenging work that leverages their intellect and other gifts. People don't like the drudgery and tedium of endlessly rote tasks. A procedure that demands your team asks a customer what their account number is when you already know it is torture. 

Knowing something and not using it is a pet peeve of mine - especially in these times when technologies like RPA and AI have combined to transform the economics of customer service and operations management completely. The cost of procedural robotics has and will continue to fall. The cost of AI prediction is doing the same. Together, transformational change is possible. It is now eminently possible to use these tools to leverage your known knowns in powerful ways. When a customer is trying to give you their money in exchange for your services, don't interrupt them with questions you when you already have the answer!

Things that were unimaginable to know and automate just a few short years ago are now possible. Concepts like machine learning are making the cost of knowing and predicting cheap. It is now unforgivable to not be working to improve situational awareness and your ability to leverage the known to create an improved customer experience and corporate value. 

This I know.

To learn more or open a conversation with Van, head over to https://evermore.biz