How do we ensure our staff read instructions aloud?

Question

As Jakob Nielsen demonstrated:

On the average Web page, users have time to read at most 28% of the words during an average visit; 20% is more likely.

We have a business application used by call center staff to carry out transactions on customer accounts. Our testing has consistently shown that our staff don't read important messages aloud to the customers.

For example, we have a transaction that makes a significant change to a customer's account. We want staff to read out the 3 bullet points (around 40 words) to the customer on the phone. This is to ensure that the customer understands the consequences of the transaction. The vast majority of staff skip over the text and try to click 'next'.

We have tried reducing the copy as much as possible, and using visual prompts to highlight important text, but these haven't made a measurable difference.

What can we do to encourage staff to read out important messages in our business application?

Answer 1

You can't force them to read something, but you can:

• Mitigate the cases where they're instinctively skipping it.
• Remove the benefit for those intentionally skipping it.

As Alan Cooper puts it in About Face, you need to "hide the ejector seat lever" and break their flow.

• TL;DR:
  • Users who intentionally skip instructions should be held accountable.
    • Also remove the benefit of skipping the instructions.
  • Users who accidentally skip instructions should have their flow broken.
    • You should only break the flow if it's actually important.
    • I suggest a timer method which breaks the flow without annoying the user.
    • But this is often a sign that you're showing too many unnecessary messages to users.

Note: The OP requires that the user reads the bullet points out loud to the customer everytime.

---

1. Use a Timer

Some critical systems I've encountered use a timer to make the Next button inactive for a set amount of time.

By breaking their flow you stop them from instinctively pressing the button. The length of the timer should represent the minimum amount of time it would take to read the text to the customer.

Once the user has finished reading the points to the customer, the button will already be selectable and thus requires no effort on the users part.

This means that it won't annoy the user, unless they're breaking the rules by not reading the bullets to the customer.

It also means there's no benefit to not reading out the instructions.

---

2. Use checkboxes

Another suggestion is to put a checkbox next to each bullet point and force the user to select them to make the Next button active.

Put the instructions at the end of the paragraph. Something to the effect of:

Select the checkbox beside each bullet point to continue.

This would ensure that the user has to parse the information to some extent before continuing.

This method is often used in online banking:

But in this example, Natwest uses the method too trivially by including it under every notification.

Only use flow-breaking methods when absolutely necessary...

... use them too regularly and they'll become part of the flow rather than breaking it.

---

3. This might be a deeper issue altogether

Perhaps you're showing them too many unimportant messages? Causing them to instinctively dismiss all messages.

Alan Cooper also says to "avoid unnecessary reporting":

If you must use them, reserve notifications for events that are outside the normal course of events. If your users benefit from knowing things are running smoothly, use some more ambient signal.

---

4. What about the users who are intentionally not reading the bullets?

UX can't provide much help here, but you can review their conversations and make them accountable for not following protocol.

One way UX can help is to remove the benefit of not reading the instructions. The timer method I describe above does this.

Answer 2

We are not talking about Facebook visitors, but professional users in the business environment. Simply hire people who understand what they are doing. No UX improvement can be a replacement for that.

Answer 3

Don’t make them read it

I'm guessing your call center staff is like everybody else's:
Unmotivated and paid as little as possible.

How do you make them do anything? You do it for them.

Record it 🤖 💬

Record the critical messages and embed them in the application. Make the employee click a button to play a recording of the message as part of their workflow.

Pros:
Use your best voice talent on the message; force employees to play the recording to continue.

Cons:
It's weird to communicate via recording; your employees feel even more like monkeys than they did before 🐒

It's a business decision

Weigh the engineering cost of that feature against paying the employees more to create stronger performance incentives.

Answer 4

EDIT: AFTER QUESTION TITLE CHANGE

Now that the question has completely changed, I want to edit my answer to fit the question.

This question, now, is definitely slightly beyond just user experience. Ensuring the staff's activity is like setting up regulations for their behaviors which cannot be achieved by UX changes.

However, If the sound controls are out of the staff's reach, an audio cue like,

"Pay attention to our executive for the upcoming information"

should do the trick. It has certainly made sure that the stewards and stewardess' on flights go through the safety demos flight after flight.

BEFORE QUESTION TITLE CHANGE

As Joel Tebbet mentioned in his answer, forcing an action from the user is a great way of getting them to read. I do not disagree but, it doesn't truly make them read it.

How many times have we actually read the T&C despite clicking on the "I Agree*?

My suggestion is to go with the step-by-step walkthrough approach. In the OP's case, just two steps: One to inform, the other for the user to convey that they've read it.

I agree that not having the Skip option makes the user hyperventilate but for important instructions (like, in case of banking applications), this might be a good idea.

PS: I know this isn't the best approach but I am certain this would get more users to actually read.

Answer 5

Most of the answers here are applicable to a typical self-service application, but you've specifically asked about a call centre situation. This means the UX should be optimised for users who are familiar with the screens, and you have more control over your users' behaviour (because they are working for you).

Typically in call centres staff have a strong incentive to minimise the call time, and they will do this by cutting corners when possible. Not reading out that message is an easy corner to cut to reduce their call time by 20 seconds.

There are two basic approaches you could take:

1. Convince staff that this message is too important to skip. This might be through an on-screen change, or it might be through a separate training session that covers the purpose of the messages and the consequences if the customer is not aware.
2. Prevent the staff from saving time by skipping the messages. This could be by adding a timer to the screen, or it could be through call monitoring and disciplinary procedures if the message is not read out.

Answer 6

The vast majority of users skip over that text and just try and click 'next'.

Given that your users are obviously looking for the 'next' button, why not change the text of that button to something more indicative of the consequences of their action?

For example, instead of a button that says , you could have one that says something like instead.

See also: Should I use Yes/No or Ok/Cancel on my message box?

If an action is really dangerous…

…you could opt to force your users to type out their action. For example, GitHub uses this when deleting your account:

Of course, this route should only be chosen if an action would have such serious, irreversible consequences that it's worth inconveniencing the user like this.

Answer 7

The deeper issue here, if I understand certain details in the question correctly, is less the UX/psychology of skipping instructions/text that the Nielsen quote is referencing (which is often best dealt with by refactoring so as to not need separate instructions), but instead making sure that your own personnel are correctly following a script and reading it across the phone to a client.

While it's true that in this case your personnel are themselves users of the software—while the client across the phone is a user of the service—the issue is a bit different from the usual UX seen with people failing to read text, as instead your personnel are failing to perform their job duty in rendering that text into spoken dialogue so that the end user client can even be presented with the related informational content at all.

QA and general process conceptualization

How are you checking that your personnel are staying on script in general? You need to have a process (or multiple processes in place) for this. Your personnel are not new or naive users of this system: they are trained employees. They are presumably using this system continuously throughout the day. They are effectively (or will be) expert users of this system, and the considerations change in this case from someone who is seeing each element for the first time, and from audiences who represent a varied makeup of skill levels and familiarity with those elements. While UX of the software is still important to make sure they are not needlessly struggling with the system or being made to feel like they are wasting time on needless, suboptimal interactions with the system, given their repetitious use, remember that their training is also a UX element of the overall system (beyond the software).

Agent Feedback, Client Communication Refactoring

Before we lock things down, consider that if your agents are skipping something repeatedly, they may think they have a good reason to do so.

This does not mean that their reasons are necessarily "correct," but it may be worth finding out why they are skipping the problem parts and what their thoughts are regarding them. If your agents do not think it is important to tell the clients the information that is presented in the script, maybe it is worth reconsidering how that information is worded to the client, and whether that information can't be presented differently or more directly and succinctly, perhaps in the form of a direct question to be answered by the client for each part of that information rather than as simply a set of statements:

Your account is going to … Because of some things that maybe you don't care about but we're going to tell you anyway because we think they're important to us and so they should be to you too And that means your account is also going to … So you're ok with all of that?

pause for input

versus

Are you ok with your account … ?

pause for input

Please affirm that you are also ok with your account … due to this change

pause for input

Do you have any questions or require further explanation?

pause for input

Note that refactoring communication to the client into concise, encapsulated queries instead of long statements also helps prime the agent for actually reading the query to the client, as they need the client's input for the application.

When conversing over the phone, breaking up information into small pieces that each require confirmation from the client also ensures that if the client doesn't understand part of the process, they have an opening to ask related questions. When communicating over an audible medium, and particularly where there are no related visual cues between speakers, it is important to give opportunities for communication to be both ways.

Otherwise, it's easy to see where someone such as an agent might assume that all of that information is either too much or must be ultimately irrelevant, because the client could be assumed to either already know it or be overwhelmed if they don't and it's presented all at once.

Set Script, Stay on Script

Make the entire process more of a set script with an emphasis on staying on the script. This helps ensure that the entire process of reading from the script is rote and that they do not deviate from what is presented to them to read. Make sure it is emphasized in agent meetings and training that deviations from the script may incur liability for the company, because they are acting as representatives of the company in reading from the script. What types of disciplinary action are in place for agents who continually deviate or otherwise potentially create liability issues for the company? Notifying them of that should be included in training, meetings, and individual feedback sessions/performance reviews.

If you do not have a set script for the entire process, and are instead letting agents communicate through the process themselves up until the point of the text you want them to read, I suggest that you potentially have a problem with your overall process. No one likes reading rote phone scripts, but they are necessary for consistent service, and they also provide degrees of assurance to agents in terms of what is ok to say and what isn't to a client. The rote aspects of reading from a fixed script for the entire process help ensure that important details aren't left off (like the ones you are currently having trouble with).

• While it's fine to explain why something is important, one mistake I often see made in UX in general is explaining the importance of something that is not optional, at a time or in a format where it distracts from immediately continuing a task properly. If the agent is supposed to read the entire script verbatim, then you should not be explaining why certain portions are more important than others: their job is to read the entire script, not to make decisions about which parts they deem ok to skip. Having an explanation of the significance of part of the script mixed into the script itself is unnecessary: I would keep any explanations of significance about specific portions to things like meetings and trainings. The core understanding the agent should have when reading the script is that they have to read the entire script as their job duty. While knowing the "why" is a comfort, psychologically, and can certainly be explained when someone is interested in understanding in a different context, it can also become a point of confusion and unnecessary timely cognitive load when it occurs in the midst of performing the task and when there is not actually a choice present in the performance of that task, which makes it both extraneous and distracting from the agent's actual work.

Script Controls, Flow interruption

For crucial parts (and only to be used sparingly, or you risk creating far too much unnecessary frustration and the same rote behavior you were trying to avoid), make the agent initial that part of the script. Do not use buttons, it's too easy to simply click through a button to dismiss it, and people are effectively trained to do so by generalized customary rote (all of the various forms that require ticking off an agreement to something that is rarely if ever actually ready by anyone). Provide a text entry, and for the purposes of assigning personal responsibility, make them initial it themselves (not with the client's initials). You can have them enter their initials at the start of the script, if needed, as an agreement to read the entire script, and then check these portions against those initials (I'd recommend against using their recorded full name in the system for that purpose: not everyone initials with the exact initials of their full legal name and/or some systems fail to properly represent a person's full name properly). This helps emphasize that they are responsible for having read aloud those portions. If the client's agreement is also something that needs to be specifically recorded and having a strong record of that agreement is important, I would suggest having a separate input for recording that agreement.

Design Language

Use consistent and separate design language for both instructions to your own agents and verbiage/dialogue your agents are supposed to read verbatim to the clients across the phone.

• Keep extraneous verbiage directed to the agent to an absolute minimum. Keep it clearly separate from the dialogue meant to be read to the client. These are presumably people who will be trained on performing their roles over the telephone to represent the company to the end user clients over the phone. They will presumably be reading these scripts repeatedly quite a lot in their job roles. Not only do they not need to see an explanation, but it also can make their jobs harder, in terms of switching between reading something to themselves and repeating as they read something aloud to the client over the phone.

• I would recommend making use of both collapsed instructions that the agent can open if they are looking for help in the middle of a customer interaction and/or using a column layout that keeps instructions for the agent in a separate column from the dialogue the agent is supposed to be reading, so that a very practiced agent can simply read straight down the dialogue column. Even if there are branching options/etc, the column layout helps fix the modality (reading dialogue aloud to someone else) into a clear spatial representation and separation.

Super ugly example of concepts covered, please don't use it the way it is:

Note that while color was essentially used to convey differences in flow, it's using an inverted scheme for the focus/action items in addition to the change in color, making it usable for individuals who are color blind. Adding a word to indicate that the agent needs to pay attention, such as "STOP!" at the beginning of each related action dialogue may be helpful to also accentuate such dialogues for agents with visual impairments, but ideally would not be needed (training on agent interaction with clients is hopefully the better focus). Another example of visually distinguishing the spoken dialogue from the system interactions with the agent would be to use rounded speech dialogue bordering for the portions to be read aloud, if you wished to have it in bordered regions/etc.

Also please see the above segment on Client Communication Refactoring for a potentially better way to reformulate this over simply having the agent read an entire paragraph/etc to the client all at once.

Answer 8

I'm sure it's important to read it once, but what about the second or third time a user does this transaction? I think a lot of times users bypass instructions because they already know or think they know what you are trying to tell them.

Force them to read it once with a controlled progression where they have to press next or check some box. If it's that important, put each of your three points on a separate page. But keep track of who has read it, and offer a bypass the next time. Otherwise, it's going to be a painful experience for repeat users.

Answer 9

Make users prove they read the instructions.

For example...

Part 1

"Here's an important message. Read it carefully, there will be a quiz."

Part 2

"Quiz: What did the message say?" (Multiple radio buttons with different answers)

Part 3

"Correct answer. Congratulations! You passed the quiz. Now we know you understand the important message." (Or) "Incorrect answer. Sorry, you have to read the message more carefully. Redirecting to message..."

Answer 10

I think a lot of answers here are biased because usually user is the target.

Here, we have customer, say bank account owner that wants to change anything via phone call, and user, an employee of the bank where the account is governed.

Obviously, the customer must be informed about consequences their request may/will lead to and user is annoyed by reading the very same information again and again and again...

The mandatory option here is that the customer hears the warnings, who will say that warnings is optional. Is it possible to read the warnings prior the customer is forwarded to the operator?

If not, try to explain it to the users why reading it out loud is a must and insist on confirmation, that they understand and accept it. If they still hesitate to read it out loud they may cause lawsuit for you and they are worth sacking.

You can make the calls recorded, which may force the users to follow instructions.

If even this fails, you can try to add voice input to the program, use voice analyser and check the words to be said at given step.

Answer 11

Building on other answers, for your specific use case I propose:

Timer + Highlight

Time (approximately) how long it takes to read each bullet point aloud to a customer. Prior to enabling the "Next" button, start all three bullets off in a slightly greyed/faded state. Hold for a second to allow them to read the top instruction (e.g. "You MUST read these points to the customer before continuing:"), then highlight the first bullet point. Leave it highlighted long enough for them to read it to their customer, with a tiny bit of extra time for a pause (which gives the customer a moment to absorb what they were just told). Then, fade that bullet out and fade in the second one; repeat for the third. After the allocated amount of time on the third point, fade it out and enable the "Next" button.

The highlighting serves to draw focus to each point, and for those with reading disabilities or the like, provides visual tracking for which point they're currently reading aloud. By disabling the "Next" button the user is forced to read the points aloud, or sit on the phone in an awkward silence as the purposely ignore the procedure. Hopefully in the latter case, your jurisdiction and policies allow you to monitor and/or record customer calls, and it'll be fairly easy to call offenders on the carpet: "so, we listened to a recording, and you just sat there and BSed with a customer when you were supposed to be reading the bullet points. Is there any reason you chose to intentionally ignore what was being shoved in your face on the screen?"

Answer 12

From what I understand, there is a fixed text that the user (an employee) has to read to a customer and this text appears so often that the user gets bored and skips it.

Additional to the other reasons, it might work to take some repetitive work off your employees, by prerecording the text, so the employee only has to press a button to play the message.

This means:

• You can be sure the text is read exactly the way you like it
• Your employee benefits by having a few seconds where they don't have to talk (which, in a call center, is a quite nice thing)
• The customer gets a few seconds of text that was recorded by a professional speaker in a studio environment, which means it will be easier to understand

Answer 13

Here is a crazy suggestion: Voice recognition to advance to the next screen. Here is the beauty of it, it doesn't have to be good voice recognition. If your voice recognition regularly misrecognizes 30% that is fine as long as you have a 50% match to the script, you can enable the next button. Adjust the match requirements based on actual mean and standard deviation of errors you actually see in testing.

Answer 14

I remember the article where Jacob Nielsen showed his concerned towards the percentage of text read by the users.

3 months back we had a similar problem and that time we used some visual hacks to make the points more visible and intuitive and also some gamification along with some slight and playful animation which made it more prominent for the users what I am reading and what will appear next.

Gamification can help in several ways like, on every bullet point, a user can interact by marking it read, make it a star point and adding a comment and each interaction will have a reward.

a great example would be this thread; you are giving away 100 bounties and to earn that people are literally putting their inputs and hence you can verify that these people are reading your question.

Still, just a suggestion. All upto you. :)

Answer 15

"We want the user to read to the customer on the phone 3 bullet points (around 40 words) to ensure they understand the consequences of the transaction."

I'd use the checkbox method (see above answer) and phrase the bullet points differently.

Ask the customer:
"Do you agree this change is a big deal?".
[Checkbox] Confirmation received from customer.

So the tickbox indicates that they have received confirmation from the customer, in which case they had to read it out aloud.

Accompany this with training, listen to recordings of the calls to ensure they do and take whatever action you deem appropriate if they don't.

Answer 16

Have the next button read out the text as a recorded message and disable any further action until it is finished.

Answer 17

Editing my answer, since the question has since been sharpened.

These are mandatory work instructions. Such as it is, the job of design here is to convey that to the user. Reflect that in the visual hierarchy:

(First element in order, and the most visually prominent:)

"Read the following 3 bullet points aloud to the customer on the phone:"

(Second element in order:)

"Bullet 1" "Bullet 2" "Bullet 3"

I echo whomever suggested a 2-step wizard in a modal window. The best way to increase the user's focus is to take away all competing distractions and force the user to consume the content in the order you dictate.

Think of a those awful pre-roll video ads. We hate them because we have to view them in order to view what follows. That stepwise model is actually useful here.

Answer 18

Customers could ask for the consequences of the transaction.

For example

Stuff member's question: "Would you like to hear 3 important consequences of your transaction?"

Customer's reply: "yes" (stuff member is obligated by the customer to read the consequences)

Customer's reply: "no" (customer took the responsibility)

Answer 19

Record it once and configure your phone system to play it (obviously without disconnecting either caller) when call-workers press the appropriate button on the phone. They're unlikely to skip it because they get to "take a break" while the message is playing. Most business phone systems support this sort of thing if you dig around in the settings although obviously it get's tricky if there's 50 different versions of the same message.

Answer 20

In general if UI reinforcement of the Business Process is not enough, there are technologies that may be used, but might be expensive for such a short process, but could be developed. What would be needed is :

1. The submit button being disabled in the begging of the Call.
2. Call Monitoring -> The Audio conversations Agent Audio Log would need to be monitored via either Call Recording software or port mirror (only works on VOIP enabled networks) This may be done without customer consent as you are only recording the leg of your own employees.
3. Audio Stream can be sent to Server running speech recognition containing a grammar for the appropriate language and the expected inputs. Some pbx have build in functionality available for this via MRCP or similar technologies also MS Windows Servers come with build in speech recognition that may be used free of charge).
4. The server that handles the speech recognition should interact with the WebPage (Potentially using CTI or similar technologies) enabling the submit Button.

In short there is a technological path possible. Concrete solution would require a little more knowledge on the type of Call Center Software used, for concrete interest talk to your Cisco , Avaya, or whatever provider you use and ask them for potential information about such a use case.

So as this is possible, sound to me like this type of solution approach would be best described by the German Proverb : "To shoot at sparrows with cannons"

Answer 21

In my opinion the crucial goals of an ideal system should be these:

• Users who are following the instructions (i.e. already informing the customers what you want them to be informed of) should face minimum disruption and annoyance or additional steps. i.e. For them the systems should be unobtrusive and in the background. They need not even be aware that anything has changed or that you have systems in place to make them pay attention.
• Users who do not do the task that you want them to should see the system intervene and nudge them to do the task. Worst case the system should even stall till they toe the line
• The system should have as few as possible "false positives" and "false negatives" when it decides its action based on what kind of user it is dealing with on the current call.
• The system should give the user the option to override it in the rare case that the system is wrong.

Here's one thought / solution but this may need a bit more effort on part of the systems designers:

• You already have access to their voice stream
• Voice recognition systems today have reached very high quality with minimal errors in transcription. Easily exceeding 95% correctness even on free form text.
• In your case the text is not free form but highly scripted.
• Suppose your UI shows those bullet points maybe in orange ("the nudge") to start with.
• As the call proceeds the Voice recognition is trying to capture and compare against the script shown in each bullet point. As soon as (say) 50% matching words are found to a give bullet point we are fairly certain that the user has indeed covered that point. So then the system changes the color of that point automatically to say green.
• Unless all oranges turn green the system refuses to activate the next button
• For the rare case that the system makes an error each orange bullet point has an override tick box that the user can tick to indicate that he has indeed read that bullet point but somehow the voice recognition has goofed up and not acknowledged it. This allows for a Plan-B in the rare case without frustrating the user.
• The "override" option can appear only after a certain timeout so that users are not tempted to casually use the override boxes. Users who use the "override" tick boxes more than a certain number of times are identified and manually counselled or any system bugs are identified
• If even better voice recognition accuracy is desired then at the startup phase the system can make each user read the scripted bullet points a couple of times to the system so as to train the system's voice recognition engine.

I realize that this may be a bit of work to integrate the solution but I suppose if it's worth doing then it's worth doing well. Noting how cheap and reliable consumer grade voice recognition has become I see no technical barriers to implementation.

I also agree that this isn't purely a UI-oriented-solution but I think sometimes a more holistic approach leads to a better solution.