Tesco – How “systems” get in the way of a good CX

tesco_chat

It’s been a few years since I buy my groceries at Tesco.com, and so far I have no complaints. It’s easy to search and buy on the mobile app, they are always on time and drivers are very nice.

Truth is, several times, drivers would call me asking where was the building, which I would find strange. Some time ago it happened again. And this time the driver said “it would be easier if the address had the building name“.

I double-check my account details. In fact, it had the flat number, street and post code, but not the building name. When trying to amend, I realised I couldn’t as the post code lookup would only bring up the flat number.

So I decided to contact Tesco, by chat (in my opinion the most convenient assisted channel). James, the customer service agent, was very nice but could not resolve my issue. Why? Guess… because of the “systems”.

You can see for yourself on the screenshot above. James told me that he could not amend my address manually, that it would take 4 to 6 weeks for the IT team to fix it, and that I needed to make note on the “delivery instructions” field.

The consequence of this response is obvious…

  • Staff Experience Decrease – No freedom to resolve customer’s issue; Frustration; Irritation.
  • Efficiency Reduction – Driver going in circles and taking more time to find the delivery address.
  • Increased Costs – Driver forced to call customer in order to confirm delivery address.
  • Customer Effort Increase – Customer required to replicate same comment in every order.

This will make Tesco deliver a poorer Customer Experience. Not only for the concerned customer (in this case, me) but also to other customers who are waiting for their orders. When their turn comes, the driver is already delayed and stressed.

Notice that this started with a very simple query: Can I (or you, Tesco) change my address? Something that is mundane and, I’m sure, a very frequent request from customers. How can the answer be so complicated? (and 4 to 6 weeks, really?!)

Important to say that it is not the system’s fault. The responsibility lies on those people who designed and implemented processes and systems, in a way that it does not allow an agent to resolve the simplest of the requests.

Customer Portal: Proactive Chat triggers and definitions

Triggering chat offers on time

The default setting of 0 for the seconds attribute does not mean chats are offered immediately (after 0 seconds). Instead, it means chats will never be offered based on the amount of time customers spend on a page.

However, you might decide that the amount of time spent on a page is a valid trigger for offering a chat. If you want to offer customers a chat session if, for example, they have been on a page for 60 seconds without any activity, you can set the seconds attribute to trigger a chat at that time.

To trigger chat offers based on page time, add the seconds attribute to the code so it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”60″ />

Triggering chat offers on number of searches

The default setting of 0 for the searches attribute means that chats will never be offered based on the number of searches conducted by customers. You might decide to use number of searches as a trigger for offering a chat. If customers have conducted several searches without finding what they’re looking for, an invitation to chat might be useful.

To trigger chat offers based on number of searches, add the searches attribute to the code so it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ searches=”3″ />

Triggering chat offers on profile attributes

The default null values for the profile_ attribute means that chats will never be offered based on customer profile information, but you might decide to set those values because you want to offer chats based on customer profile information.

When you configure the ProactiveChat2 widget to offer a chat based on customer profile information, you must define all three profile attributes for the widget: the profile item, the operator, and the value.

Let’s assume you want to offer a chat to all customers from ABC International, which has an organization ID of 81945. In that case, the widget code would resemble the following.

<rn:widget path=”chat/ProactiveChat2″ profile_item=”org_id” profile_operator=”equals” profile_value=”81945″ />

Triggering chat offers based on customer SLAs

If your organization requires SLAs in order for customers to chat with agents, you’ll want to verify that the customer has an SLA with available chat incidents before a chat session is offered. The profile attributes of the ProactiveChat2 widget can do that for you.

An SLA defines the total number of incidents a customer can submit, as well as specific numbers of chat, staff member, email, and web self-service incidents.

To check for chat SLAs prior to offering a chat, add the profile_item, profile_operator, and profile_value attributes to the code for the ProactiveChat2 widget. You will want to set the slac item to be greater than zero to be sure the customer has remaining chat incidents available on their SLA. You will probably also still want to include the seconds or searches attributes so the chat invitation is not immediately offered when the customer lands on the page with the widget. Your edited code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ profile_item=”slac” profile_operator=”greater than” profile_value=”0″ />

Editing the chat invitation

By default, the chat invitation says “A Chat Assistant is available to help. Would you like to start the session?” That message can be edited by editing an attribute of the ProactiveChat2 widget.

To edit the chat invitation, add the label_chat_question attribute to the code so that it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ label_chat_question=”Staff members are available now. Would you like to chat with someone?” />

Changing the chat login page

When customers click Yes to accept the chat offered by the ProactiveChat2 widget, the Live Help page opens by default. You might want to direct customers to a different page instead.

To change the chat login page, add the chat_login_page attribute to the widget code so it resembles the following. Note that the path to the page must begin with /app/.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ chat_login_page=”/app/chat/alternate_chat_launch_page” />

Defining how the chat login page opens

By default, the chat login page opens in a new window that lets you configure its height and width. You can also set the chat login page to open in the same window.

To change the size of the chat login window, add the chat_login_page_height and chat_login_page_width attributes to the widget code, defining the new values for height and width. Your code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ chat_login_page_height=”500″ chat_login_page_width=”600″ />

To open the chat login page in the same window, add the open_in_new_window attribute and set it to false so your code resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ open_in_new_window=”false” />

Determining product or category

By default, the ProactiveChat2 widget tries to determine the product or category by evaluating search information or product/category information from an answer or incident page. It “guesses” to the deepest level that can be found and then, if product/category information is available, that information is sent to the server to determine what queue the chat request should be routed to, whether agents are available for that queue, and what the estimated wait time is. You can disable this feature for either product, category, or both.

To disable product or category determination:

  • To prevent trying to determine what product should be used to route the chat session to a specific chat queue, set the guess_prod_val attribute to false. Your code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ guess_prod_val=”false” />

  • To prevent trying to determine what category should be used to route the chat session to a specific chat queue, set the guess_cat_val attribute to false. Your code will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ guess_cat_val=”false” />

Defining the minimum number of agents

If the seconds, searches, or profile attributes of the chat widget have been met, an AJAX request is made to the server, which sends back the number of available agents. If you have defined the minimum number of agents required to offer a chat session that value will be compared to the number returned from the chat server. If the number of available agents is greater than or equal to the number you defined in the min_agents_avail attribute, the chat is offered to the customer.

To define the minimum number of agents, add the min_agents_avail attribute to the widget code so it resembles the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ min_avail_agents=”2″ />

Defining the maximum wait time

If the seconds, searches, or profile attributes of the chat widget have been met, an AJAX request is made to the server, which sends back the wait time for a chat session. If you have defined the maximum time the customer will have to wait in a queue, that value will be compared to the number returned from the chat server. If the wait time is less than the value you defined for the wait_threshold attribute, the chat is offered to the customer.

To define the maximum wait time, add the wait_threshold attribute to the widget code so it resembles the following. Note that the wait time value is measured in seconds.

<rn:widget path=”chat/ProactiveChat2″ seconds=”30″ wait_threshold=”60″ />

Note: It is recommended that you set min_agents_avail to 0 when you set the maximum wait time.

Triggering a chat offer by an event

If you want to trigger chat offers only when a specific event occurs, you must first create an event called evt_customProactiveInitialization using custom code. Then set the initiate_by_event attribute of the ProactiveChat2 widget to true. This tells the widget’s logic file to listen for the event before triggering a chat offer.

Note: For specific information about defining evt_customProactiveInitialization, refer to the initiate_by_event attribute definition on the Customer Portal Administration site at http://<your_site>/ci/tags/widgets/standard/chat/ProactiveChat2.

Customer Portal: Proactive Chat

You can offer your customers an invitation to a chat session if they have conducted searches without finding the results they are looking for. You can do this on your customer portal pages, and you can also offer a chat session from any external page on your website.

The following summary of events occurs when a customer accepts a chat offer through the ProactiveChat2 widget or the syndicated ProactiveChat widget.

  • Before the chat is offered to the customer, the chat session routing rules determine what queue the chat request will be directed to based on products, categories, custom fields, and other rule conditions.
  • When the customer accepts the chat request, the chat page that opens contains by default any incident custom fields that have chat visibility. If you have edited the page to add the ability to select products or categories, they will also appear.
  • If the customer changes any of the information on the chat page, that information is passed to the agent on the chat session workspace. However, the rules engine does not run again. As a result, the customer may change a field that would have triggered the chat being assigned to a different queue, but because rules are not run on the updated chat page, the original queue assignment does not change.

Chat sessions are not offered in the following situations:

  • If the customer’s browser does not accept cookies, no chat is offered during the customer session.
  • If the widget looks for a chat queue ten times without finding one, no chat is offered on that page.
  • If a chat is offered (whether or not it is accepted), a cookie is set and no more chat offers are made during the current customer session.
  • If a chat is offered and the customer refuses, a cookie is set and no more chat offers are made for 30 days.

Offering a chat on customer portal pages

You can put the ProactiveChat2 widget on any page. RightNow Chat must be enabled and agents must be available before a chat will be offered to a customer. Additionally, the customer’s browser must be configured to accept cookies.

Important: The default code for the ProactiveChat2 widget will not trigger a chat offer until you add an attribute that defines the trigger for the offer. Therefore, you must add at least one of the following attributes to the code: seconds, searches, or profile attributes. If you do not specify one of these, the widget will not offer a chat session. Alternatively, you can define an event that will trigger a chat offer by creating a custom widget based on the ProactiveChat2 widget.

To add the ProactiveChat2 widget to the Answers page

1. Open the list.php file in the /views/pages/answers folder

2. Locate the following code.

<rn:widget path=”reports/Paginator” />

3. Add the following code immediately after the code you found in step 2.

<rn:widget path=”chat/ProactiveChat2″ />

4. To trigger the chat offer based on the customer’s inactive time on the page, add the seconds attribute to the code, which will resemble the following.

<rn:widget path=”chat/ProactiveChat2″ seconds=”60″ />

5. To trigger the chat offer based on the number of searches the customer conducted, add the searches attribute to the code.

<rn:widget path=”chat/ProactiveChat2″ searches=”3″ />

6. To trigger the chat offer based on the customer’s profile information, including organization, SLAs, and default product and category, refer to the section “Triggering chat offers on profile attributes” on this post.

7. To trigger the chat offer based on an event, refer to the section “Triggering a chat offer by an event” on this post.

8. Save list.php.

Configuring the ProactiveChat2 widget attributes

The default code for the ProactiveChat2 widget will not trigger a chat offer because the default values for the seconds, searches, and profile_ attributes are 0. You must define at least one of these attributes before the chat offer will be triggered.

When one of these attributes has been met, an AJAX request is made to the server, which then sends back the number of available agents and the minimum wait time. If a product or category can be determined through search terms or answers or incidents viewed, the queue ID for that product or category is also returned. This information is then matched against any additional widget attributes.

You can configure any of the following ProactiveChat2 widget attributes

– Chat triggers

  • Number of seconds on page
  • Number of searches conducted
  • Profile attributes (profile_item, profile_operator, and profile_value)

– Display and function

  • The wording of the chat invitation
  • The chat login page that opens when customers accept
  • Whether the chat login page opens in a new window or the same one
  • Attempt to guess product or category

– Chat availability

  • The minimum number of available agents
  • Maximum wait time in queue