Features July/Aug 2020

Collaborating to Build Collaboration: The Role of Content Experience in Real-Time Support for a Newly Virtual Conference

By Jenifer Schlotfeldt and Nic Sauriol

As COVID-19 wreaked havoc on the world, IBM had to make the difficult decision to cancel its annual customer conference. For the first time, however, the company decided to create a digital-only version. Forty-seven days prior to the conference and counting, a multidisciplinary team collaborated to provide a first-of-a-kind conference for IBM. Content would come to play a critical role in the massive success and further serve a critical role in real-time dynamic learning and sharing.

The conference development team focused on figuring out how to host the conference in IBM’s cloud environment and bring all the tools and technologies together to pull off a virtual conference. But as the broader team shifted to understand what attendees would need during the conference to provide a signature experience, major gaps emerged. How would we support this audience with a new registration flow and a new, real-time attendance toolset? This wasn’t a traditional situation where a “docs” team provided customer-facing manuals. Instead, we heard the following:

Can you help enable an army of volunteer support people from all disciplines across the company and turn them into all-star support agents who can handle 100,000 potential visitors with questions ranging from “Where is this session?” to “Why am I not getting any audio?”?

That’s when our special set of skills became in high demand. Our Content Experience team is a cross-functional, highly collaborative group of content, user-experience design, and development professionals who regularly collaborate on the IBM Cloud product. We were being asked to bring that successful collaboration to ensure a successful conference support experience that would be handled by volunteers with no experience and would require a high degree of real-time collaboration to be effective.

Content Experience Advocacy to the Rescue

To start, we crafted an email to recruit 100 volunteers to staff a live chat during two days of the conference. Not surprisingly, there was no support team waiting and available for this situation. So, we had to look to volunteers to make the conference support successful.

The conference team members knew they wanted to provide FAQs for each tool the attendees might interact with, and they were building a chatbot to provide the first line of defense for attendee questions. We knew that providing editing support for the chatbot would be important. This included testing by asking questions that we expected the attendees would have and ensuring that we received bite-sized, conversational responses.

We then quickly turned to live chat. If the attendees couldn’t get the answer they needed from the chatbot, they could ask to speak to a live agent. Cue our 100 volunteers. Our Content Experience team was presented with a folder full of presentations, spreadsheets, and notes full of FAQs, and we had three weeks to pull together a way for our army of volunteers to collaborate during the conference.

The team had to research and model, as best we could, not only the questions but the frequency at which we thought those questions would be asked. For other, more problematic questions, we needed to understand the context and provide background information for the support agents. For questions related to individual user contexts (such as an individual’s specific system), we had to provide as much information as possible for a support agent to debug issues. This modeling drove the overall structure of the approach to support our volunteer support agents. We considered how to train a brand-new agent to handle escalations, attendee frustration, unexpected questions, and more. To complicate matters, these new agents were busy IBMers, so we didn’t have weeks to train them to handle this entirely new role—we had hours.

As the team began building the training materials, we put ourselves in the shoes of the volunteer support army that would be responsible for answering questions about tools they didn’t know and a conference they didn’t plan. The primary goal was to provide answers to attendees as quickly as possible, so they could get back to the conference. We needed to pull together all the content into one accessible place. We needed to build a support site that would serve as the handbook for all the support agents, and we identified the following key features for the site:

  • Search
  • Good content that could easily be copied
  • Easy-to-update content

Most important would be the team’s ability to react and change. We had no idea how close our initial guesses on questions would be, as we had never done this before.

Starting with Search

Because the army of volunteers wouldn’t have deep technical or support knowledge on any of the tools, or any in-depth knowledge of the ins and outs of the conference, the key was enabling them to find the answers efficiently. This wouldn’t happen by having an assortment of spreadsheets, presentations, and notes open on their desktop. In addition, these documents were organized by the tools supporting the conference, and not by how users would be interacting with or using them.

Increasing the stakes, most of these soon-to-be support agents had never even been on the receiving end of a client anxious to get an answer, and those clients were likely going to be eager to attend an important session that they might already be late for. It was critical that the answers be accessible when both the agent and the client might be frazzled.

Scripts

If we wanted the live agents to have speed of delivery, we needed to enable them with content that was ready to be delivered. For each error condition or area where we expected attendees to have questions, we provided clear background information for why the attendee might encounter this situation or what might be causing it.

Then we provided copy-to-clipboard versions of scripts that the virtual agents could reuse in their conversations in the live chat, as shown in the example in Figure 1. This was critical, as these were agents who had hours, not years, of training to prepare to handle client questions on the fly. We wanted to ensure that, as much as possible, we could help them by embedding experienced-agent phrasing and tone into their default answers.

When we recruited volunteers, we didn’t have the luxury of handpicking for the unique skills we thought would ensure agent success. Given the number of agents we needed, and the fact that we were asking people to volunteer, we required only two skills:

  • The ability to politely engage with attendees
  • The ability to look up common problems from our support site
Easy to Update

The publishing environment needed to be accessed by hundreds of IBMers, and we needed to make continuous updates to the content. Although we leveraged the FAQs that each of the tool teams provided to initially populate our site, we knew we wouldn’t catch all the scenarios that attendees might encounter during the conference. Thus, instantly refreshing the site as needed was key.

This seemingly small decision about the publishing environment was ultimately a critical one that enabled our content to become what was effectively a rich, real-time collaboration environment and the keystone of our support system. What we developed became a just-in-time answers engine that took any single question asked of an agent and turned it into a committed update available to all other agents within moments. The result was that we had countless on-the-fly updates, and when agents weren’t actively answering a question, they were funneling all questions through to our content team in a continuous conversation.

For the volunteer army, we held a training session, making sure to offer it multiple times to hit the availability of each of our volunteers. This was going to be our first feedback opportunity! For most, it was their first time seeing the support site, so we weren’t expecting to get feedback on the content. What we did get was volunteers asking questions about the live chat tool they were going to be using and anticipating the types of questions they might get. This was valuable in filling in a few more content gaps.

Then it was game time. We had the support site writers available to collaborate with the all-volunteer army in a private chat. As volunteers came on the clock and reported new issues that attendees were experiencing, we could quickly provide new scenarios in the support site with those tailored scripted answers. As each new wave of volunteers came on board, the answers were there—just waiting to be searched and provided to the attendee.

Conclusion

Ultimately, we learned about how “docs” could be evolved to pivot into a model of rich, just-in-time collaboration that enabled a large group of people to take on an entirely new skill domain confidently and successfully. There are many ways that documentation can serve a pivotal role in enabling richer client conversations with our engineers, support, and beyond. In this way, documentation can serve as a rich, authoritative medium that serves as the keystone of collaboration between our teams. It might not have been “docs” in the traditional sense, but those same team members, skills, knowledge, and content provided customer-facing content.

 

Jenifer Schlotfeldt (jschlot@us.ibm.com) is a senior content strategist and the content experience architect for IBM Cloud. Jenifer leads a team of software engineers and content designers who own the IBM Cloud Content Experience. Not only is the team supporting the continuous delivery of the IBM Cloud Docs and API Docs, but they also embrace DevOps and Design Thinking practices. She is also the coauthor of DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.

Nic Sauriol (sauriol@ca.ibm.com) is a development leader for user experience and analytics at IBM Cloud.