How to Design for Experience Continuity – with Context Cookies

One of the most burning challenges in the customer care industry is how to keep track of what customers are doing across the various communication channels – so that they don’t have to repeat themselves to different agents, or when coming from self-service. At Aspect, we have come up with the technology of Context Cookies to help with that problem. Context Cookies are quite similar to browser cookies, in that they are small data bits that “remember session state”. Different from browser cookies, though, they must be stored in a central repository: we call it the Continuity Server, a key component of Aspect’s self-service platform, CXP.

As an example, imagine calling a business and interacting with their IVR. Halfway through, your call drops. Wouldn’t it be great if you could just redial and continue from where you left off? That’s what Context Cookies enable.

What else could be stored as context cookies?

• Dropout points in IVR interactions
• Business tasks that weren’t completed on last call
• Last transaction performed in mobile app
• Last time the customer talked to an agent
• Last issue discussed with agent
• Most recent page of your website the customer visited
• …

Storing the cookies is one part of the job. The other part is enhancing your mobile app, SMS service, agent desktop, IVR, website etc. to perform “write” operations through an API into the Continuity Server. (The more the better, but don’t think that you have to do this all at once. Starting with intra-channel continuity is better than offering no continuity at all.) But what do you do with the knowledge that is now in the cookies? When do you pull it up, and how do you execute upon that knowledge?

I believe it comes down to 3 key things you want to remember from recent interactions:

1. Task: “WHAT did you do last?”
   1. Authenticate?
   2. Pay a bill?
   3. Get a status update?
2. Time: “WHEN did you contact us last?”
   1. 3 minutes ago?
   2. Last night?
   3. 5 months ago?
3. Channel: “WHERE (on which channel) did you contact us last?”
   1. IVR?
   2. Web chat?
   3. Mobile app?

In order of decreasing importance: Knowing WHAT your customer did last lets you continue where they left off. Knowing WHEN they engaged last (or when YOU reached out to THEM) lets you decide if the most recent interaction is likely still relevant to the current outreach or not. Knowing WHERE they reached out to you (or you to them) lets you add additional context with your response.

So how do you let your customers know that you know this? On IVR, or with your agents, you could announce it this way:

It’s really as simple as that. If the answer to this question is “yes!”, then shortcut the IVR experience directly to the module where they can resume that last task. Note that you can ask this question as soon as you have identified who the customer is. This could be based on the caller ID, or any other unique identifier that you already use for your IVR self-service (or routing) application.

On the visual channels, you can do the same: rather than a “voice” pop-up, show a traditional visual pop-up window right after authentication, to lead the customer to the point where they will likely want to go:

If you are curious to find out if you can design for this experience with your own existing IVR, mobile, or Web offerings, please reach out to us!

The post How to Design for Experience Continuity – with Context Cookies appeared first on Aspect Blogs.