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
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.
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.