Legacy is a term used rather inaccurately in our industry. When applied as an adjective, it’s supposed to mean, “denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use.” When often used by cloud providers, the term infers “premises-based, old, outdated, and irrelevant” technology. I would reasonably argue, that the “so-called” legacy vendors had it right in many areas. The cloud vendors could learn a lot from their predecessors, especially in the areas of quality documentation and education.
Quality documentation admittingly is tough to write; as a technical education facilitator, I prefer instruction over documentation writing because I can elaborate or demonstrate a topic or concept in different ways for comprehension. I can draw out a diagram or flow chart, use different analogies, and demonstrate using the actual application. Furthermore, I can see the participants’ response, understanding, or lack thereof, by asking questions, requesting chats or opening up for dialogue in a virtual setting.
The document writer, who usually has never taught the application or sat in for instruction, ends up writing documentation based on developers’ notes and testing the application. They often don’t know there tends to be more than one way to design a contact routing scheme, and the impact of doing it in different variations may have on the statistics available for reports or other nuances that the application may have. That knowledge and experience is gained over time, in multiple customer implementations with different business requirements; each question asked during a course or implementation has the instructor or designer thinking about the flexibility the application has or doesn’t have to meet the customer needs. The lack of a feature spurs on requests for enhancements in future releases.
The problem with documentation is that it requires completion before the product or application is made available. Or at least this should be done before the release is published. With the timely delivery of new features or releases, documentation and training have often become an afterthought to many cloud providers. The “plug and play” concept also seems to downplay the requirement for quality documentation or education. Documentation can always be enhanced and improved if made a priority.
Here's one example where some cloud documentation could be enhanced. Most contact center applications require an agent to log in with a username. The definition of that field by one vendor in their documentation is:
Username—The name that a person should use to log into the environment. You must specify a value for this property, and that value must be unique within the configuration database.
That seems straightforward. Yet, the explanation says nothing about whether this field is case sensitive, if special characters are required, how long the username field is, and so forth. In this same document, there are no screenshots of the agent parameters within the application to guide the user. If the individual is trying to use the documentation to add a new agent, they may have to guess how to enter the information. Now, the vendor probably has online help, but that digital assistance should match what’s in their downloadable PDF document.
When I recently queried two cloud vendors, I noticed a lack of documentation when I asked about their data dictionary. This significant document for data and reporting analysts usually contains the database design and data element definitions of the historical reporting and real-time parameters contained within the contact center application, including examples of any standard reporting in the system. The data dictionary would define what the equation is for service level, or whether talk time by definition includes the time the customer is put on hold, and so forth.
One vendor said its data dictionary was located only online, element-by-element viewing, but wasn’t available for download in a PDF file. Another echoed something similar but added it didn’t want “customers printing paper and negatively impacting the environment.” First of all, a PDF document doesn’t need to be printed; they’re great for perusing information, highlighting, and making notes. The decision to print should rely on the customer, and I thought that was a lazy excuse for not providing it. What’s even more irritating is this vendor provided the data dictionary documentation for releases one to three in PDF form, but didn’t for its fourth product release. It seems to me that a vendor not willing to put documentation in a printable form is trying to hide something. As a consultant when I am evaluating a vendor for customers, documentation and good training carry a lot of weight. This vendor has lost many points in my book by their silly response and lack of continued documentation.
Now, just a few of my observations on the training provided by some contact center cloud providers. First of all, I’m amazed that most of them are offering education during the implementation phase, and require many of their customers to implement a fair amount of their own design or else there are extra professional services costs. That may work for some customers, but for many, time is critical and on-the-job (OTJ) training during implementation isn’t optimal.
Course instruction seems to be in lacking strong environments and instructors with experience. I observed this when sitting in on a customer onsite, in-person led course, where the instructor showed us all the various parts of the application, but no documentation was provided or referred to, and no practice exercises or tests were made to see if it actually worked that way it was stated. When I asked my customer if the other course module was better, they said it was a different, more experienced instructor teaching, yet no reference to documentation once again, more of a show and tell. Even if there is good documentation for the system, an instructor usually provides some supplemental material and has practice exercises to instill the knowledge.
Virtual instructor-led learning is offered for most vendors today, and onsite courses are becoming rare for obvious reasons. Virtual instructor-led learning definitely has its advantages and its place. But as we get into the more complex applications of contact routing, the importance of testing designs, and trying different scenarios, often the virtual environment lacks the ideal set up for good robust testing. I’ve found that the contact routing courses, and overall administration set up and design is often best taught in the traditional in-person classroom with proper documentation, demonstration, and practice exercises for participants to test and try. Often, participants will ask me the questions; instead of jumping to give them the answer, I have them test it out themselves on the system and work with other students to verify their findings.
There are all sorts of learners out there. I’m one who likes to learn from the “expert” without distraction; my experience of teaching virtual classes, participants are still checking emails and being distracted by other work. Whether you’re at home or in the office, people still believe you’re available and interrupt. Being away from home and office provides the time and space for learning the more complex aspects of the application.
Customers spend lots of money and time putting in various cloud contact center applications and with the good implementation, documentation and training customers could get a lot more value out of their investment.
