Skip to main content

Customer Experience

Patterns of Customer Experience

This is the first in a series of posts around patterns in customer experience as it pertains to omnichannel customer service.


My wife and I are currently in the midst of a move to a smaller house that is more accessible. We are starting with a somewhat open slate and using an architect to help us. While discussing this with a childhood friend of mine, he brought up Christopher Alexander’s A Pattern Language. This mention surprised me. My friend is not tech and is unlikely familiar with the so-called “Gang of Four” book, Design Patterns by Gamma, Helm, Johnson, and Vlissides. Which is how I knew about Alexander’s work.

Alexander’s work primarily concerns architecture, urban design, and community. But it also established the concept of a “pattern language.”

The Wikipedia entry states:

“The book creates a new language, what the authors call a pattern language derived from timeless entities called patterns … In doing so, the authors intend to give ordinary people, not only professionals, a way to work with their neighbors to improve a town or neighborhood, design a house for themselves or work with colleagues to design an office, workshop, or public building such as a school.”

This concept was a foundation and inspiration for Design Patterns (GOF). And GOF is probably one of the more influential books in our industry. It established a vocabulary and mode of communication far beyond those that have read it. And that has endured since publication in 1994. Ask any excitable React programmer what a Higher Order Component is. He will descend at least partly into a description of the Decorator pattern from GOF. Or, if you are lucky, into a semi passionate pontification of the differences.

The point and value here is we all use domain-specific languages when we discuss and think about specific environments, design, and problems. Alexander introduced and GOF extended a framework for creating pattern languages, a process to identify patterns and establish consistency in how they are formatted, communicated, evaluated, and used. The end result is a reproducible, collaborative, empowering language for anyone working within a domain.

A Customer Experience Pattern Language

This brings us to Customer Experience as it pertains to omnichannel customer service interactions. Programmers, user interface designers, systems architects, and even project managers all have some pretty well-established pattern languages in use. And while they provide great value on that level, it got me wondering just what the pattern language is for customer experience in an omnichannel digital customer service world. Rewriting the wiki quote to something like:

“giving contact center professionals a pattern language for use in designing, building and evaluating customer interactions, to improve customer experience, and to work with colleagues, customers, and their businesses to assess how well those interactions perform from both a customer and business perspective.”

So I set about starting to think about and ask some of my colleagues here at Perficient and our customers for ideas on patterns they might see or identify. It’s just a start, but well, you get the pattern. For this initial installment, we will start with one of the most basic patterns. Hopefully, it will help establish the structure and approach for future entries and ideas.

Customer Experience Patterns

Prioritize Human Contact

Let the customer easily talk to a human.


We are social creatures. While automation can offer tremendous value, the ultimate resolution when the process breaks down is human interaction. Customers caught in an IVR with no way out will get extremely frustrated. The same applies to a poorly designed chatbot or virtual agent. In automating interactions, never lose sight that one party is a human, with an underlying motivation for the interaction. It’s impossible to anticipate all cases. Sometimes your customer just needs to talk to someone.


Always provide an easy out to any automated interaction, be it a declarative flow (IVR) or a virtual agent. Always support a global exit to speak to an agent. Within virtual agents, intents are used to capture the motivation and reason a customer-initiated an interaction. For example, “book a flight.” While designing your virtual agent, be sure to capture any intent that is remotely akin to “agent,” “human,” “representative,” etc.
In the end, the implementation and assessment of your IVR / virtual agent and the ability to capture and deflect interactions is your responsibility. Don’t deflect bad interaction design onto your customers. The onus is to constantly refine, assess and tweak your self-service implementation to meet needs quickly and effectively. But always allow for the edge cases and exceptions.

Implementation Options

  • Use AI/NLP tools such as Google Dialog Flow, Google CCAI, or Amazon Lex to create interactions that always include a speak to an agent intent that is reachable from anywhere
  • If there is trepidation around wading into the world of NLP/AI and virtual agents and bots, then enlist a partner with experience and resources to help. The AI Team at Perficient has extensive experience in using state of the art NLP/NLU tools to build best in class virtual agents.
  • If not ready for a full-fledged virtual agent world, leverage speech recognition native to your tooling. For example, within Twilio Studio, include speakable menu options at every decision point that provide an easy exit for your customer

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Andy Gilbert

Andrew's first profession was as a Russian linguist, but not a very good one. He did discover computer programming as part of that experience. He has been working as a developer, architect, and manager in the technology space for over 30 years. And was a principal in one of the first true SaaS hosted communication platforms.

More from this Author

Follow Us