LiveOps Blog
Five Reasons to Choose a Multichannel Product for Social Media Customer Service
Keith McFarlane, CTO, Platform and Telephony, LiveOps
Social media is disrupting customer care in ways that are both profound and difficult to predict. Not only do contact centers need to effectively manage voice, email, SMS, and chat traffic, they’ve also got to deal with tweets, wall posts, likes, dislikes, pins, blog comments, etc. This is an ever-expanding list of social media message types that grow in volume by the day. In short, the contact center is moving from merely chaotic to completely insane.
Until recently, contact center owners have had no choice but to deploy new social media monitoring systems that have no relationship with existing (and already disparate) contact services. Due to this, contact centers are becoming unmanageably complex, and customer support agents are being pigeonholed into unnatural specialties based on media channel type.
Fortunately, new technology solutions are emerging to address these problems. If you are in the market for new contact center technology, you should consider a vendor that supports all of the contact channels you need now and plans to expand coverage of new channels as they emerge. There are many reasons for this, and I’ll cover five of them here.
1) Support for Cross-channel Pivot Scenarios
Detecting social media activity related to your brand is important, but it’s only the first step; that initial @reply or direct message may not be enough to address the customer’s issue. You will need the ability to “pivot” from public forums like Twitter and Facebook to more private, interactive channels like voice or email. For example, you might want to provide a link in your direct message that generates a voice callback from a contact center agent, who then can directly address the problem surfaced in the original tweet.
Implementing the channel pivot capability using several disparate customer contact systems (one for voice, one for social media, etc.) can be incredibly challenging, but these scenarios are supported very naturally in an integrated customer engagement environment.
2) Keeping Up With Changes in the Social Media Landscape
Twitter and Facebook support are obvious requirements of any contact center solution now, but several years ago this wasn’t the case. Pinterest went from an unknown service to the 4th largest social network within months. Conversely, MySpace, the preeminent social network prior to the Facebook explosion, has gradually settled into near-irrelevance.
Social networks emerge, grow, contract, and explode in unpredictable ways; because of this, contact centers need to align themselves with innovative vendors that are focused on the ever-shifting tides of the social media waters. At LiveOps, we have developed a social media connector architecture that allows us to quickly connect to new social networks and use new capabilities of existing social media networks. For example, we recently added the ability to route new tweets to agents based on location data.
3) Providing a Unified Agent Experience
There’s no good reason that a contact center agent should need to use more than one desktop tool to service customers across different contact channels. In fact, switching between applications and browser windows can seriously impact an agent’s effectiveness. Because of this, convergence of desktop applications is often a high-priority IT goal.
Contact center technologies that support multiple contact channels have the opportunity to provide a consistent, rational user experience across those channels. In the case of LiveOps, contacts from multiple channels are displayed and manipulated using the same basic visual tools, with some special channel-specific tools displayed as appropriate (for example, ability to choose @reply vs. direct message when responding to a tweet). Also, agents can decide to service the customer using the original contact channel, or pivot to a more appropriate channel for the context.
4) Reporting Across All Engagement Channels
Historical reporting and real-time monitoring are among the most important functions of any contact center solution. Unfortunately, these reporting and monitoring needs are very difficult to satisfy in a multi-vendor environment. At the most basic level, matching customer and interaction records makes any data rationalization project problematic and often expensive, involving weeks or months of consultant time.
This is one area in which multichannel solutions shine brightest. Since all customer contacts are managed by the same platform, data is consistent by default. There is no need to spend time and money merging cross-channel interactions or customer records. With LiveOps, an agent or supervisor can see a customer’s cross-channel contact history instantly in a contact center dashboard, enabling a more engaged, effective customer experience.
5) Cross-channel Application Development
For every new technology a contact center implements, IT developers and consultants must take a new programming interface into account. Implementing voice call, email, and Twitter processing separately forces the IT application developer to write applications using three different APIs. This leads to higher development costs and longer time to deployment.
Compare this to a multichannel vendor with a single, consistent API. While developing a new CTI-driven application, for example, the application developer is also learning elements of the API that will be applied when integrating with the Twitter or chat channels. The contact center IT staff can build up knowledge of a single platform and apply it many times over.
As you evaluate vendors for your next social media contact center project, be sure to ask the question: “How can your product make my life easier?” If the answer doesn’t include simplification through multichannel support, you should really keep looking.
Building a Better Hackathon: Four Core Principles from LiveOps Hack Day
Keith McFarlane, Chief Architect
We recently held our eleventh LiveOps Hack Day event, and it was something special; a number of really interesting ideas came to life in a mere 24 hours thanks to the efforts of some very passionate and dedicated teams and individuals. A few of the hacks shown at demo time were:
- Pivot to Video – the team involved with this one found a way to move a live agent chat conversation into the world of video using Tokbox.
- Multichannel Visualization – our reporting team presented a new way to look at the overlapping streams of work an agent handles while dealing with multiple work items simultaneously.
- Agent Telephony in-Browser – the engineer showed off integration of our agent phone panel application with Twilio‘s JavaScript-based Client, enabling voice calls using a PC alone.
- Scriptable Callflow – some of our platform engineers found a slick way to control granular telephony functions via REST API.
We have worked to improve Hack Day over the years since we held the first event, and while we have made many incremental changes, we have also identified a set of core principles that can make or break the event depending on how closely they are followed.
1) Great hacks come from the heart, not from the backlog
All too often, I’ve seen engineers or product managers try to use Hack Day as an excuse to accelerate their favorite backlog items. While this certainly accomplishes something useful, it defeats the true purpose of the event: innovation. Developers should use this time to pursue their wildest software dreams and try out new technologies. The same is true for product managers; they should team up with developers to integrate with other web services in unexpected ways, or to make an attempt at defining and implementing an idea that would seem risky under normal circumstances. It should be an opportunity for exploration, not business as usual in a slightly different order.
For developers, picking a backlog item as your hack day project is essentially thumbing your nose at the product management team’s priorities. Think of all of the thought and discussion that has gone into getting the story order right for your scrum, and then imagine ignoring all of that work and selecting stories at random. Clearly the former is preferable to the latter.
Hack Day is about allowing great ideas to emerge from unexpected places. Without emphasis on pursuing new ideas rather than existing ones, it loses most of its value.
2) Focus, focus, focus; scope creep kills hacks dead
While any new idea should be fair game for hack day, I’ve noticed that the greatest successes come from small, focused efforts that aim to complete a minor but valuable feature, or to demonstrate a large concept through a well-defined example that is limited in scope. Often, projects like this can achieve success early, and then add features as time permits. Also, because the victory conditions are well-defined, the team can abandon the hack if it proves too complex, and move their focus to some other idea.
All developers have “big concepts” floating around in their heads; unfortunately, these can be the most difficult to build, even in limited form, as part of Hack Day. If you want to successfully pursue one of these grand schemes in hack form, draw more people into the discussion and find a small piece of the puzzle that stands well on its own, but still gets your point across.
3) Sometimes it takes a village to create a hack
Certain hacks are so clearly defined and limited in scope that a single developer can make them happen on time; however, as complex as most web services are, it is far more common that any truly interesting hack will require the efforts of several subject matter experts across a number of different platforms.
At their heart, hackathons are social events, and they are just as much about teaming and morale as they are about innovation. If you are organizing a Hack Day event, provide a forum for team formation prior to the event itself; we have held a pre-Hack-Day “recruiting” meeting for several years at LiveOps, yielding teaming combinations that might not occur within the normal flow of project work, and fostering greater interactions between teams over the long haul.
4) Deployment is the best reward
Yes, it is important to offer some sort of tangible “best hack” prize, although everyone who wants an iPad probably has one already. However, not every developer has a product idea of their own running as a feature in production; many engineers can work at enabling the visions of product managers for years without their own innovative notions seeing the light of day. If hacks show promise as products, or if they are immediately usable, they should be fast-tracked into production for both the good of the company and as a reward for the engineers involved.
Every software company (not just web startups) should hold regular hackathons to engender innovation, increase motivation, and improve the lines of communication between teams. As with any company activity, however, there are more effective and less effective ways to go about it. Keep track of what works and doesn’t work, make improvements over time, and listen to participant feedback. Although the principles above have worked very well for us at LiveOps, you will more than likely evolve a set of guidelines that work better for your organization over time.
Five questions to ask when choosing a cloud-based contact center
Jeremy King, EVP of Technology and Products
“Truly tested” is a phrase I don’t throw around lightly. But LiveOps’ decade of experience in managing a cloud-based workforce amounts to a virtual lifetime in our increasingly digital world, making LiveOps’ platform one of the only “truly tested” cloud-based contact centers in the industry.
Sifting through the moving parts of a contact center can be daunting but we’ve weathered enough storms at LiveOps to know what to look for. In an industry where needs change quickly, experience matters.
Here are five key questions to ask when deciding to migrate to a cloud contact center provider. (more…)