by Ken Agress | March 18, 2013 | Comments Off
In my last post, I described issues that arose when the credit union we have been members of the changes to their online services. In and of itself, making changes to your corporate webpage isn’t necessarily a huge issue and enterprises do this all the time without invoking the rest of their customers. However, the changes that occurred this time not only impacted the overall utility of customer portal, they also had significant follow – on impacts for financial institution by having a dramatic effect on the customer’s ability to use software such as Quicken.
In this day and age where the voice of the customer and the customer experience receiving significantly more attention as a means of brand differentiation, customer retention, and revenue enhancement these types of issues simply cannot be afforded. But what’s important is to understand the numerous ways in which impact of these kinds of changes could have been avoided.
First of all, there is virtually no chance that any significant number of customers were polled to determine how they felt about the proposed changes were given the opportunity to participate in a test group. The interface was simply too clunky, access to account information from Quicken (and most likely other financial software or websites) was too difficult, and the frequency with which one had authorized a browser, computer, or mobile device was simply too high. Now it is certainly possible that I’m wrong here, but I think it very unlikely. While I was not a member of any beta group, if one existed could not have performed rigorous testing to ensure that the changes would be acceptable to the average credit union member.
Second, there was little opportunity to view the changes prior to their implementation. Yes, we were informed that significant changes to the website were coming in that these would include alterations to the bill pay system. But many enterprises undertake these types of upgrades or alterations by offering members or customers an opportunity to explore the new interface and system well before it is deployed. This serves two purposes, not only does it allow the customer to gain familiarity with the changes that are coming, it also allows the enterprise to define where common issues are likely to occur and establish frequently asked questions or similar knowledgebases that will benefit both customer service and the customers themselves.
Third, the reason for the change was only revealed after modifications have been made: apparently, some issues had arisen between the credit union and their bill pay provider. These issues were never described with any significant clarity, which should not be problematic except that this is a credit union. The members are the owners and the decisions that are made should therefore be even more focused on the customer. Whatever these issues were caused the institution to accelerate modifications that they were making, which likely impacted things such as beta testing and involving customers.
Fourth (and finally), the rollout itself in the support provided after the rollout simply failed to make the grade. When you website first went live, for example, the link to the help screen presented you with a "404 error" rather than providing you actual content that might avoid a call or email and customer service. The authentication method selected required a two – step process that was confusing, and impossible to initiate from anything other than a web browser that was directly accessing the credit union’s site. And for the first two weeks after the upgrade, there was no possible connection to Quicken or other financial software because changes to the update mechanisms had not been made at the time of implementation. As these types of issues became clear, the institution began offering training sessions to introduce the customers to the new webpage in the way that it functioned. But this occurred weeks after the initial implementation, and still didn’t address many of the underlying technical concerns. To this day, these concerns continue to plague my access to my own financial information on the platforms that I prefer to use.
Although it is certainly possible that my credit union could’ve captured my feedback and acted upon it with greater alacrity and implemented a range of voice of the customer customer experience management technologies, this misses the point. Before these technologies can pay their maximum dividends, they need to fit in to a customer service process and customer experience process that focuses on the customer in the first place. They need to be a part of the culture the responds quickly to customer concerns, and in particular attempts to understand and rectify negative opinions that are provided as part of the service process. Even more important, customer needs to be engaged prior to making significant changes even if those modifications involve some urgency for the enterprise, such as issues with a partner or service provider.
I really cannot complain about the service that I did receive when I interacted with an agent – they were prompt, polite, and is helpful as they could be. But that ultimately wasn’t the issue in the first place. The problem is that the customer experience had not been put first and foremost for something as crucial as access to financial information, accounts, and transactions. And although these agents are polite and helpful, it hardly addresses the fact that months after this implementation the website and supporting services are still difficult to use. It also does not explain why an increasingly negative sentiment that I expressed over the course of many interactions was not treated as a more serious issue. Even when I notified them that I was seriously considering moving my accounts to another institution with online access that suited my needs more appropriately, the only response was a polite notification that my message had been received and forwarded along. There’s been no further follow – up since that message.
This underscores an important point that any enterprise needs to consider, but particularly needs to focus on if there is truly going to be a voice of the customer or customer experience initiative: all of the talk in the world is meaningless unless the business processes that back the technology are designed to provide that excellent customer experience and respond effectively to the sound of the customer’s voice. There is no speech recognition technology, new survey provider, no text analytics, and no metric or score they can overcome disconnect in this way. The customer needs to be involved from cradle to grave in order to truly provide an excellent customer experience.
After more than 20 years with our financial institution, they are learning this the hard way with a self-inflicted wound.
Category: Uncategorized Tags:
by Ken Agress | March 7, 2013 | Comments Off
At the end of last year, my managers and I started to discuss content plans for this year, which is a fairly natural thing for analysts to do. Where do we stand with our core coverage? What trends or technologies should we give more time to this year? In those discussions, we focused on the “Customer Experience” and specifically the “Voice of the Customer,” since these technologies cover a vast landscape of solutions – surveys, speech/text analytics, social mining, profile/personality creation, etc. The sheer number of different vendors that have staked a claim to these technologies is somewhat staggering, and there’s more than a bit of confusion related to this array of solutions, approaches, architectures, and delivery methods. Little did I know that these discussions would invoke some karmic chain of events that would help focus my thinking in a number of ways.
You see, late last year, a financial institution my family has used for north of twenty years made a decision to make changes to their web site and electronic services, notably the ability to synchronize transactions with Quicken. At the time, the reason for these changes wasn’t presented as anything more than a relatively “routine” overhaul of their portal, backend platforms, etc. This was a relatively normal change to services that are well understood throughout the financial industry for providing customers with secure, timely access to their accounts, transactions, and services.
I could not have been more wrong.
As the roll-out started, the changes immediately started to raise red flags. For one, the institution had opted to alter its authentication mechanism. This isn’t a big deal – the approach they had selected was arguably more secure than a simple ID/password combo and had the added benefit of changing the ID so that it wasn’t an account number. That’s fine, but it quickly became apparent that the way that it authorized individual systems was cumbersome, erratic, and often failed to “stick” – after a week or two, you had to repeat the process. At first, I figured that it was because of the security settings on the PCs we used automatically cleaning out cookies or temporary files, but when I tested that theory by either excluding the institution’s domain name from the sweep or turning of the “cookie killer,” it continued to occur.
But the most shocking thing was one simple fact – the changes that the institution had made broke the ability to automatically synchronize transactions with Quicken’s “One Step Update.” No more opening our software and having the information pulled in, the connection simply failed. And even when the connection succeeded, there was no way to have authentication happen. Not only that, but in order to get transactions from my accounts, I had to download them in CSV format and manually import them – you couldn’t even save in the most ubiquitous file format for personal finance I can think of when the service was first rolled out.
It’s obvious I wasn’t the only one that voiced concerns – support for Quicken was quickly enabled, starting with the ability to download (an acceptable work-around) and moving to the direct connection. But the strange two-factor authentication system broke for that application as well. Which meant a very cumbersome visit to their web site using a browser that didn’t have their “magic cookie” stored because there was no way to request a new authentication code from a machine/browser that has been authorized. The system assumes that any new access is from a web browser and you can go through the request process right then and there. But you can’t always do that, which makes the system far more annoying than secure.
And this amnesia regarding the authorization of a computer or application just made life worse. Now, if Quicken lost its ability to connect directly, it’s back to a browser that doesn’t have the “secret sauce” to request the authorization. And if you use any of Quicken’s cloud services? They’ll prompt you to reauthorize regularly, too. And if you fell back to downloading transactions manually from the web site rather than jump through those particular hoops, the default settings had you pulling down six months of transactions so that you could manually roll through all of the duplicates and delete them – no memory of the last time I downloaded that file to streamline things for me.
This fell on top of a number of other issues. The interface they provided wasn’t as clean as the old one. Where you used to click on a transaction to view additional details or a copy of a cleared check, now the field you clicked on altered the behavior of the click. Click on the amount? Well, you must want to search for all transactions that have that exact amount, right? Some of these decisions make some sense (clicking on “Transfer” in a transaction description to show all transfers, that I can see). But #1 – it’s pretty trivial to add mouse-over text that will tell the user what’s going to happen when one clicks there and #2 – many of these decisions were, frankly, only “useful” if you’re in an altered state.
It got to the point that I used their internal message system to send them a detailed message of the issues we continued to encounter and our history with their service and support people. I expressed frustration over the quality of the new system which simply could not have been tested by their actual end-users in any way – it was simply too useless to make the grade for basic financial activities the way that they are often conducted today. And it closed with a very direct statement – the decisions that they had made were putting our business of other 20 years in jeopardy. I received a very nice reply from a customer service agent that apologized for the problems and let me know that my concerns had been forwarded along to management.
I’m the first to admit that I’m no Warren Buffet. Moving my family’s accounts is not going to sink this financial institution. But here’s the thing – this is a credit union. They’re supposed to be differentiating themselves from the “big banks” by providing me with better rates & service than I can get from conventional banking outlets. So I have to admit that I was more than a bit surprised that I still have not heard anything from anyone after that in over a month. And if you’ve got a customer that’s been with you for north of twenty years, that is just bad customer service even if it isn’t Warren Buffet.
As I move accounts, I have to wonder if this was the universe’s way of inflicting what I may be writing about upon me to improve my coverage and diligence. Either way, it shines a bright light on some mistakes that will be worth discussing in future posts.
Category: Contact Center Customer Expereince VoC Voice of the Customer Tags:
by Ken Agress | March 27, 2012 | 6 Comments
Yesterday morning, Enterprise Connect kicked off and I’m lucky enough to have made the trip. While my schedule at these events often makes it difficult for me to attend many sessions, I do try to squeeze them in whenever I can on the odd chance that I’ll hear something unexpected or unusual. Although these sessions can rarely go to the depth or detail I can get interacting directly with vendors, every once in a while it happens. And yesterday was one of those days.
The session focused on the question “Are we in a post-PBX era:” with the breadth of UC platforms today, is it time to bid our the PBX a final farewell and move to UC solutions exclusively? But rather than drawing my attention with a particularly well-formulated argument to support or refute that suggestion, the panelists (which included representatives from many of the largest UC vendors in the world) all settled on a relatively common statement – the most critical part of interoperability that enterprises will be leveraging in the near future is their value-added reseller. Rather than strong standards for signaling and media, the VAR will become more of a systems integrator that ties these systems together. There were somewhat obligatory noises about SIP, the UCIF, or similar standards, but the message I took away from the session was “interoperability will continue to be hard and enterprises shouldn’t expect the vendors to address this directly.”
This answer is a failure. The trends in the market are towards greater and greater use of virtualized, software-based, cloud-enabled platforms for communications. Enterprises need the flexibility of these platforms to meet the growing demand for “bring your own device” approaches to mobility, leveraging cloud-based services effectively, and connecting directly to business partners, clients, suppliers or other third parties. But what the “Interoperability comes through your VAR” answer means is that we shouldn’t expect significant developments that make such environments truly possible. Since each vendor’s focus will be on their products, their clients, their services, and their communications channels, how can an enterprise reasonably expect to connect to a carrier service, cloud provider, or external entity that uses solutions from a different vendor?
This is ludicrous. SIP was approved in 2000 with the goal of providing a standard for signaling in an IMS infrastructure. Standard codecs for voice and video are available for use. SIMPLE and XMPP offer the means needed to support presence and instant messaging. Yet in 2012 we’re still here discussing how hard interoperability is, particularly among some of the largest vendors in the industry. Worse, interoperability would appear to be either relatively unimportant in comparison with other development efforts or type of sop that the vendors can throw to their channel as an additional revenue stream. OK – that last sentence is a bit hyperbolic, but it illustrates a simple point: Rather than offering interoperability that provides enterprises the flexibility and connectivity they need by committing to fixing the problem, the vendors are referring enterprises back to their VAR.
This type of approach also hurts UC overall by limiting its applications. Want to be able to adopt a hybrid deployment model that mixes on-premise and cloud services to address different user communities? There won’t be standards to support that, so pick your platforms carefully. Want to establish a strong collaborative platform with your critical suppliers? Better either have the strength to force your platform upon them or the good fortune to all have selected the same platform. Want to supplement a specific channel or type of connection with a “best-of-breed” solution that brings you features and functions that your standard platform can’t supply? Here’s hoping that this solution “plays nicely” with your chosen enterprise platform.
For UC to deliver on its promise and move us to a post-PBX era it has to do more than “just” replace the PBX. Indeed, that’s arguably the least important thing it has to do because the PBX is really just a method of delivering voice services provided by a hardware-intensive platform that can be exchanged for a well-deployed mix of IP-enabled hardware with the right software. UC needs to provide enterprises the ability to connect to their customers, partners, suppliers, and even the public in ways that help advance their business goals. It needs to be able to consume cloud services, connect to a wide array of devices and systems, and offer its services to applications that allow communications to become embedded in those applications that support business processes and workflows.
Will VARs play an important role in many enterprises? Certainly – the deployment and integration of UC as a part of a services-based IT environment alone will call for expertise that enterprises are unlikely to have as they take their first steps. But the basic “blocking and tackling” involved with connecting UC systems together shouldn’t be so reliant upon these entities. It should be based upon real standards with real support and strong capabilities rather than the relatively weak “well, we support SIP” that we hear today. Sadly, it appears that the vendors don’t see this as critical to their plans.
This leaves the initiative in the hands of enterprises. And if enterprises are serious about receiving solutions that provide them the flexibility, extensibility, and connectivity that they desire then they’ll need to demonstrate it with their purchasing decisions. Unless purchasing decisions are driven by the interoperability and integration requirements as much as other demands, we shouldn’t expect change. Vendors do have very different approaches to integration, and a shift in the market towards platforms that offer richer and deeper support for interconnectivity will be a far more eloquent statement of the necessity for these capabilities than this blog post or any report that I can write could ever be. The question is – are the vendors saying what they’re saying because enterprises haven’t convinced the market that they’re serious? If so, then it may be wise to increase your budget projects for services from your VAR as you look towards the cloud or direct connections to other enterprises.
Category: Unified Communications Tags:
by Ken Agress | March 1, 2012 | Comments Off
I’ve yet to encounter an IT project that didn’t have to justify its budget against business needs in some way. Whether you’re deploying infrastructure, applications, or evaluating services, the funds that are being allocated need to match up against some measure of the value that the project will deliver to the business over the life of the investment. This is a continuing challenge in the UC space since numerous analysts, consultancies, and vendors regularly publish reports that seek to quantify the actual business benefit of UC technologies. It even provided the launching pad for a report I recently published on the topic (subscribers can find it here) that focused on developing a stronger understanding of where and how UC impacts business processes and performance.
Shortly after that report went in for final editing, I ended up having a conversation with a peer here at Gartner, Richard Hunter. It was one of those interactions that made me wish I could pull a report back and make some significant changes if the production cycle would have allowed it. Richard pointed out that we frequently attempt to apply the wrong metrics against business value, which can end up undermining support for a given project or effort. He noted that when an expenditure is intended to help the business “run”, as opposed to “grow” and “transform,” the most appropriate metric to apply is “price for performance.” This applies to anything the enterprise does that can’t be directly tied to a particular revenue stream, as opposed to initiatives that clearly target a specific market and customer segment (like attracting new customers, reducing the time required to provide service, shrinking the costs involved with developing a product, or similar market-focused activities). If the enterprise can’t link a project with a specific paying customer, then return on investment (ROI) is almost certainly the wrong measure of value. Total cost of ownership (TCO) and price to meet the performance requirements of the organization are better metrics for this purpose, since they express the fundamental relationship of price to performance for essential services for which no measure of return is possible, but performance requirements are clear.
Shortly after this conversation, I had a client inquiry that reinforced this distinction in a fairly stark way. The enterprise I was talking to was preparing a strategy to offer UC services to tens of thousands of employees around the globe and had positioned their UC deployment as a new suite of applications and services that would enhance worker productivity by streamlining communications and collaboration. In particular, the system would offer improvements to remote or mobile workers by extending the enterprise platforms to them in a manner that the legacy voice, videoconferencing, and other environments simply didn’t support. But they were struggling to define the ROI for the UC platform based on the expected improvement in performance that the enterprise would recognize.
The problem is – for that ROI calculation to work, the IT organization would need to be able to tie specific performance improvements back to the investment in the UC system and its deployment. This means that in addition to being able to measure employee productivity effectively, the measurement would need to be able to distinguish between any productivity improvements that relate specifically to the UC solution rather than any other initiative that the organization happened to undertake while the UC deployment occurred. That’s a tall order.
These two conversations led me to ask “why is it that we’re so focused on ROI for UC?” Despite the volume of reports and articles available, numerous discussions with enterprises demonstrate that the business case isn’t sufficiently sound to be convincing from a business perspective. The end-user productivity benefits, although perceived to be real to some degree, simply are too “soft” for business managers to find them convincing enough to fund the investment. Which caused me to think back to the consulting work on PBX platforms that I’ve done in the past. Although these project always focused on the financial aspects of a deployment, they never attempted to quantify the ROI of the investment in the phone system – they strictly focused on the ability of the platform to meet enterprise communication requirements in a sufficiently cost-effective manner.
Although I can’t say I can clearly answer that question as yet, the comparison between the two different projects does at least provide me with some clues that I think will ultimately build a compelling case. When deploying a PBX, the investment was presented strictly as infrastructure – systems and services that simply had to be available to meet basic communications requirements in a broad-based fashion. But when we turn to UC solutions, they’re typically presented as an application instead – a solution that’s designed to address a relatively targeted requirement (in this case, communications and collaboration capabilities). That’s a presentation that shares more with the way that organizations evaluate a communications platform like contact center systems rather than basic infrastructure like a LAN deployment. The application is expected to target some specific business need (e.g. reducing agent labor costs or managing agent workloads more effectively) rather than supply a fundamental service (such as providing dial tone) that can be tracked with a relatively high degree of fidelity.
In the end, this pair of interactions exposes something important for IT to consider – how you present UC to business management may have a great deal to do with the questions that you get asked to justify the expenditure. In many circumstances, it will be more effective to present UC solutions as infrastructure in the same way that we approached PBXs or Ethernet switches in the past – systems and services that provide a baseline capability that’s simply “table stakes” for the enterprise. Without the baseline capabilities, the enterprise can’t identify or deploy the interesting applications of communications and collaboration that are associated with more targeted improvements in business performance. Without the UC solution to meet the “run” needs, you can’t explore the applications that meet the “grow or transform” desires. Sure, a UC solution that includes instant messaging may provide a broad productivity benefit across the board, but unless that can be tied to a specific business activity, monitored with sufficient clarity, and reported on within the context of a specific business process it will be difficult or impossible to truly show the ROI of the solution. Which makes presenting a UC solution as an application or suite of applications a dangerous proposition. It changes the conversation from one that focuses on underlying capabilities that the enterprise simply must have to enable future, targeted applications to one where IT is implying that the solution is an application that can be measured in a targeted fashion immediately. Since many IT organizations will struggle to quantify that type of performance improvement with sufficient clarity and credibility, perhaps the wisest course to approach UC from an infrastructure and price for performance perspective rather than injecting ROI into the conversation out of the gate.
Category: Unified Communications Tags:
by Ken Agress | October 10, 2011 | Comments Off
My very first blog post asked “What’s it Mean to be ‘Unified’ in the First Place?” While this isn’t a particularly surprising question, it is interesting that in the past week I’ve had a number of conversations that raised this question again. Even more interesting, these conversations weren’t with my clients or vendors, but discussions with other analysts. The conversations basically broke in to one of two themes:
- For something to be called “Unified Communications,” the client that’s running should cover the “major” media that comprise a suite of UC interactions. For example, a client for a smartphone shouldn’t be considered “unified” if it doesn’t include e-mail and instead relies on the native client that comes bundled with the operating system.
- Alternatively, for a service to be considered a part of the “unified” landscape, it needs to offer compelling service for at least one of the major media that UC typically includes. For example, an e-mail only service could be considered a part of UC if it supplies services of sufficient quality to fill the e-mail needs of an enterprise that is deploying UC across this and other media.
It shouldn’t be surprising that I disagree with both of these views given my earlier post. The first view focuses too heavily on the capability of the client, almost ignoring the need for some central service to coordinate interactions as clients request presence information, initiate interactions, transition between media, and adds new participants or types of media to the session. The second view implies to me that the focus should not be on that central, coordinating service, but on the capabilities and strengths of the individual media, products, or constituent services that make up a broader UC solution.
Both of these discussions highlight why I think it critical to look at the core of the UC solution as defining “UC” rather than either the client or the constituent parts. The goal of UC is to enable multimedia interactions within context for the users involved while simplifying the process of transitioning between or adding new media to a particular session or conversation. A focus on the client eliminates the need for a central service (or suite of services), and particularly eliminates the need for interactions supported by industry standards on common protocols. The focus shifts to the capabilities of the developer of a given client, which theoretically eliminates the need for consolidated presence or standardized means of reporting communications capabilities or states among different media. A focus on the individual media without considering how well that media integrates into a larger multimedia environment does much the same – it ignores the importance of the unification in favor of an individual media.
Philosophically, I think this is an important point, and one that enterprises should consider when evaluating a platform that bills itself as “unified.” If a platform can’t support multiple media (even if it doesn’t bundle all of those media into a single solution) or relies on customized clients to connect otherwise disconnected services, then it’s important to question what this means from a UC governance and management perspective. How can the enterprise obtain a common view of availability, presence, or capability? How will appropriate rules for interactions (which may be driven by privacy, regulatory, or compliance concerns) be monitored and enforced? How will the enterprise extend this environment beyond the customized platform or single service to include richer forms of interaction, automation, or application-enablement?
Attempting to define UC from the client or an individual service perspective strikes me as the story of the blind men examining the elephant – since each is touching a different part of the elephant’s body, their conclusions as to what the elephant really is misses the larger picture of the elephant. And for UC, we should avoid this – the utility that UC delivers doesn’t rest upon the comprehensiveness of the client, but on the ability of the service to adapt to particular clients or capabilities. So long as e-mail is available from the client, it’s relatively immaterial if it’s supported by a disparate application so long as the service can direct communications to either according to the user’s requirements. Both a client and a service capability focus lack the “glue” that truly makes UC unified – a service that is capable of helping users or applications reach other users or applications using the most appropriate method of communication within a business context. That’s the “glue” that creates the unification of different products and services and coordinates the activities of the different client applications, communications services, collaboration services, and applications to deliver the right mix of media at the right time.
Category: Unified Communications Tags:
by Ken Agress | September 30, 2011 | Comments Off
I recently read Richard Rumelt’s book “Good Strategy/Bad Strategy: The Difference and Why it Matters” and I think it provides an important point to ground discussions about customer engagement and how it relates to the contact center. Rumelt suggests that all good strategies include a “kernel” that describes common components:
- A diagnosis of the problem
- Guiding principles to help evaluate solutions
- A coherent plan of action to address the problem
When strategies fail, they are deficient in at least one of these components. There may be a plan of action, but the problem was not defined sufficiently to make that plan of action coherent. There may be a diagnosis and plan of action, but no guiding principles were available to assist in future decision-making as the plan is executed. Without all three components available, decisions cannot be truly strategic because they fail to focus analysis and activity towards solving the right problem in the right way. This type of analysis can be particularly important when contemplating strategies to create a truly multi-channel contact center, particularly in the social arena.
In my interactions with clients, this often appears to be a problem. While these interactions often focus on strategies to create, support, or extend a multi-channel/socially-enabled contact center, the discussion is really around the plan of action that individuals are contemplating to make this environment a reality. But when we get in to the conversation, there’s little that’s been communicated about the overall diagnosis of the problem or principles that allow for concrete decision making. The enterprise knows that it needs to be prepared for “the new world” of contact centers, but lacks a firm understanding of the problems that they expect such a contact center to address or the principles that are applicable to the specific enterprise and its customer base.
This isn’t enough. The “problem” isn’t “just” enabling a wider array of interactions – that doesn’t actually speak to a business need. The “problem” needs to be defined in a way that describes how a socially-enabled, multi-channel contact center fits enterprise goals to drive lower churn, higher sales, or lasting engagement. This will different for a service organization than it will for a retail organization,or for a company that manufactures toothpaste instead of cell phones. The strategy should identify some specific expectations that must be met or targets to achieve.
One of the points that Rumelt makes in his book is that enterprises often confuse setting a goal with adopting a strategy. Rather than developing a strategy to drive new sales or reduce churn, the organization merely sets metrics or targets that it expects business units to achieve without describing the problem sufficiently. “Leverage social media to increase customer engagement” is the start of a strategy, but it requires additional nuance to make it something you can execute. Will your enterprise publish reviews of products to drive engagement? Does this mean offering tips about using products or solutions to meet their needs? Will you provide special offers, coupons, or deals? Is this a way to solicit input on features, presentation, pricing, or events?
It’s not that the contact center can’t succeed without a strategy described in this manner. But without such a strategy, it will be difficult to actually judge what worked, what didn’t, and which investments or process changes paid dividends. So before engaging in execution, it’s worth asking whether there’s a good “kernel” to start from. Has the problem been diagnosed in a way that ties it to business goals? Are there sufficient principles in place to provide direction as the strategy is executed? Is the plan of action coherent and does it involve all of the right right people, groups, processes, and workflows? If not, then perhaps the project team should focus on defining the strategy more concretely before pushing ahead. “Driving engagement” is a fine starting point. But it lacks the clarity necessary to ensure that the technologies evaluated and the processes to support them target the right kind of engagement with the right constituencies. Define the engagement strategy first, and the investments of time and money that follow are far more likely to succeed by design rather than circumstance.
Category: Contact Center Tags:
by Ken Agress | September 22, 2011 | 3 Comments
In my last post, I managed to accomplish two things. First, I demonstrated that when you don’t read back blog posts carefully you can use the same words and phrases too much, particularly when a mild cold has you a bit off your game. Second, that there may be reason to approach adding social media to the contact center with some skepticism. Comments I’ve received from various sources indicated one of two things – that enabling social media for the contact center can be quite beneficial to the enterprise if executed properly and that adding such support is inevitable as a consequence of shifting consumer behaviors. And, despite my skepticism, I actually find both of things to be true. Which means that the question isn’t “should the contact center be connected to social media?” The question is “how can enterprises stage themselves to successfully integrate social media into the contact center?”
This means that skepticism might be valid because we shouldn’t focus too heavily on the channel, but the way that the channel will be used. It’s fairly common that in my interactions with contact center customers, the focus is (rightly) on how to deliver service to customers using the applications and infrastructure that have been built out for the contact center. The view is one of a service organization with relatively common goals – service customers quickly, efficiently, and effectively. This view needs to change as the contact center shifts into the social arena because the nature of interactions in the social space is typically far less goal-oriented or focused from the perspective of the customers that the contact center is attempting to interact with.
The comments I’ve received about this last blog post universally include one word that needs to become the focus of planning for the social contact center: “engagement.” If an enterprise approaches social media strictly as a means of delivering service in a new way, it’s fairly likely to fail because there are better avenues to achieve that goal. But if social media are used to increase engagement with customers that provide for a more positive and lasting relationship between the enterprise and the customer, provide outbound information in a timely and useful fashion, gather feedback or opinions, and maintain a conversation with the customer, then we’re talking about something that can increase loyalty and provide a valuable channel to both parties.
This requires more than just connecting the media, it requires developing a firm understanding of the best way to enable engagement. This isn’t something that the contact center can do alone. It requires that the contact center, marketing, public relations, and the lines of business develop strategies to integrate social media into a broad spectrum of activities. Without this type of strategy, the contact center cannot engage in a structured and consistent fashion that reinforces messaging and strengthens branding. Worse, if entering the various social networks is poorly coordinated, the mistakes will play out on a large stage which can result in negative rather than positive impacts.
In other words, to overcome skepticism about adding social media to the contact center’s range of communications and collaboration enterprises need to focus not only the contact center, but a far broader social strategy. This needs to be built around a firm understanding of the organization’s customers, a clear definition of how social media will fit into other marketing, branding, and support activities, and well-defined ways to leverage social media to guide customers to the right resources to meet their needs. This isn’t necessarily an easy task and needs to appropriate sponsorship to achieve. Enterprises that approach social media as a part of an overall communications and messaging strategy rather than “just” as an extension of the contact center have reason to discard skepticism. Others? Well, there’s reason to be skeptical regarding the chances of success.
Category: Contact Center Unified Communications Tags:
by Ken Agress | September 15, 2011 | 2 Comments
I sometimes refer to myself as a Luddite because I can take a fairly conservative approach to things technological. Not because I’m opposed to the advance of technology as the actual Luddites were, but because I sometimes wonder whether we’re actually approaching the application of technology in an interesting fashion. Since we’ve begun covering contact centers, one area that has consistently brought this skepticism to the fore has been the adoption of social technology to the contact center space. The working theory typically goes something like this: your customers are already using social media, they’re already talking about you on social media, and you need to be able to engage them there. The implicit or explicit suggestion is that you need to be able to respond to what’s being said about your organization within the world of social media in order to meet “modern” customer service requirements.
It’s at this point that my inner Luddite arises. Not because an organization shouldn’t find ways to engage effectively with their customers – certainly, going where your customers are and being able to engage them effectively is probably never a particularly bad strategy if you apply it effectively. What summons the inner skeptic for me is one of two things: the suggestion that the contact center is the appropriate place to conduct this form of engagement or, alternatively, that your customers really want to engage with you through social media in the first place.
I’m skeptical of the role the contact center should play because it seems striking that social engagement is inherently a different form of engagement from traditional contact center activities. By the time a post has appeared on a social media site, the customer has already had some degree of positive or negative engagement with the enterprise and is sharing thoughts regarding that interaction. When their content reflects positively on the company, the engagement may take the form of a “thank you” or a special offer to encourage stronger loyalty and further activity. When the content reflects negatively, it’s already in the social space and therefore becomes less about customer service and more about public relations. The organization is working to demonstrate responsiveness and concern and/or mitigate the potential damage from a negative review or comment.
I question whether this is a “contact center role” not because the people that work within the contact center are incapable of providing the function, but because this strikes me as being more than a customer service function. It’s a public relations function. If a paper or analyst publishes something regarding a company that is potentially damaging, it’s not the individuals in the customer service department that generally undertake a response – it’s the PR group or marketing group that become involved because the publicity and potential damage are the issues that they are responding to. This may sound quite similar, but in reality is a nuance with some important impacts. For one, if the response is ineffective or escalates the situation, then the damage that may be inflicted upon a brand or company is magnified. For another, it can easily be viewed negatively regardless of the quality of response. “Why did I have to go complain on Twitter/Facebook/LinkedIn to receive quality service?”
The second reason I’m skeptical deals more with the behaviors of the customer in the first place. Although there is no question that customers do want to engage with companies through social networks, is there any compelling evidence that these individuals are looking to social networks as an outlet for customer service? When individuals “like” a Facebook page or follow a Twitter stream, it certainly appears to this analyst to be an expression of interest in keeping up-to-date with what the company or brand is bringing to the table. What’s the latest and greatest product? What new features are on the block? What’s on sale? This is valuable to the enterprise to be certain, but is a very different form of engagement than a customer service function. Further, engaging with a customer based on a social post may be viewed as intrusive and inappropriate – “You’re monitoring my tweets? Really? Why didn’t you just fix the problem when I called…”
This is not to say that I’m sufficiently in the Luddite camp to suggest that the capabilities that socially-enabled contact center infrastructure provide are useless. Certainly, they are not. But I think we need to be careful about the strengths and weaknesses that these capabilities have and what they mean for customer engagement. The goal the contact center should be setting is to avoid the need for responses to issues that hit social networks – build and deploy a service infrastructure that provides quality service in the first place and keeps the number of people with something to vent in a tweet or status update low. Then leverage the strengths of socially-enabled infrastructure to verify that these efforts are meeting with success and build upon those efforts. And, while doing that, sort out the right ways to offer engagement that leverages social media by providing a method of connecting the customer to the contact center for help when they’re seeking service.
There’s no question in my mind that social media will evolve to play an important role in the way that we offer services as contact centers. But it seems striking that from a service perspective, focusing on mobility, tighter multi-channel integration, and more effective use of contextual information (all of which “socially-enabled” contact center infrastructures typically offer) are likely to realize higher dividends for enterprises. For one thing, they can hopefully be used to ensure that what appears about an enterprise in social media streams is positive to begin with. For another, it provides enterprises with time to improve service while aligning organizational responsibilities and learning more about how customers want to engage in the first place.
Category: Contact Center Unified Communications Tags:
by Ken Agress | August 25, 2011 | Comments Off
I have to admit: preparing this first blog post has proven to be one of the more interesting challenges I think I’ve faced since joining the ranks of the industry analysts. I hope that I’ve managed to pick the right topic, present a clear case, and stimulate some interesting conversations/interactions, and look forward to your feedback.
Covering both unified communications and contact centers provides for an interesting mix of perspectives. On the one hand, I interact with clients that are evaluating ways to deploy UC in a manner that demonstrates real business benefits. On the other hand, I’m working with clients focused on optimizing the contact center to meet a mix of performance and business goals. In both cases, the trends are clearly pushing organizations towards environments that can support numerous communications and collaboration technology, which naturally “fits” a discussion of the UC products that are available on the market today. Yet somehow, neither really seems to bring a view of being “unified” that resonates with any particular regularity. This is further reflected in the contextual research work that my colleague Mark Cortner recently published. Which raises interesting questions: Why isn’t there a particularly consistent message that “works” across a range of environments? And what, specifically, does it mean for an enterprise to offer “unified” communications or “unified” communications and collaboration in the first place?
Certainly, we don’t lack for definitions of UC or UCC. There are definitions proposed by vendors, by analysts, and even by some industry groups. Most focus on the idea of a system that merges multiple forms of communication and collaboration into a single, compact framework that is easy for an end-user to consume. Many build upon this further by extending the definition to include automating or streamlining business processes (arguably, something that high-end contact centers do on a regular basis). Still others specifically call out the ability to offer access to communications from more devices and locations to enable mobile users, telecommuters, or travelling staff to connect to the corporate environment. And one would think that one of these definitions largely satisfied the need for a common framework that lays the foundation needed for enterprises to leverage the technologies in play successfully. Yet somehow, this doesn’t appear to be the case. And I think that it may be the definition that isn’t necessarily sufficient.
If we begin discussing UC from the premise that it’s a means of bringing together many different modes of interaction, then it’s worth asking: “What’s the foundation that provides this unification?” Realistically, this particular definition of “unified” for UC could focus almost exclusively on a “fat” client that’s running on an individual user’s computer that has all of the necessary plug-ins, add-ons, or code to make use of a number of different services and force transitions from one to the other through “brute force” methods that did little more than hide the call control functions from the end user. On my personal computer, I use such a client that can aggregate different IM and voice services and present me with methods to transition between them when I’m interacting with my contacts there. With just a bit of work, I can even transition from one service provider’s network to another if I configure my contact lists right. It will even aggregate presence information from these various sources so that I can select the best method available for reaching my contacts. So am I running “UC” on my PC?
I suspect that most of us would answer “No, UC isn’t just about client software. It’s an enterprise service.” And that’s a good answer. But it doesn’t quite go far enough because when most individuals talk about “UC,” they’re often referring to a specific product or solution that’s on offer, typically from a vendor that they happen to like. Even when this isn’t readily apparent to the individual I’m talking to, just a bit of interaction tends to reveal a sub-text that can often confirm this suspicion, and even reveal which vendor’s platform they happen to be leaning towards. Which begs the question – if the answer revolves around a particular product definition, how different is it than my somewhat ridiculous suggestion that UC lives on my personal computer? After all, when we look to communicate outside of a UC context, we don’t necessarily put the vendor who’s tool we’re using at the forefront of our thinking. We think about the connection we want, not the vendor that provides the hardware or interface.
And perhaps this is where we could all approach UC a bit differently. Fundamentally, UC is about an aggregation of services, not endpoints or software. So maybe our definition of “unified” should focus less on what is being unified or how that unification is presented and more on what we should expect from a service that coordinates activities among many other services. This has a number of advantages when considering UC platforms and solutions. First, it focuses thinking on “What can it do” rather than “Who can I buy it from?” This requires that we technologists look application rather than vendor and consider the service in the context of business uses. Second, it requires that we think less about a suite of services (that perhaps we can purchase from Vendor X) and instead describe how the unification service itself should behave. This puts the emphasis on solutions that allow the UC service to abstract the specifics of any given mode of communication or vendor solution from the end-user or application, requiring that the solutions we think about do more than just call the right API or module on the client to establish a connection. The service itself should provide the necessary proxies, gateways, and control to remove that requirement. Third, it allows us to think about how UC fits into a broader IT environment that includes applications, infrastructure, security, and access methods without predisposing us to any particular approach to the problem. Instead of worrying about how to integrate Vendor X’s solution with Vendor Q’s ERP or CRM application, we can instead define the way we expect a UC service to contribute to the overall environment and fit in to the broader IT architecture.
In many ways, these approaches reflect some of the learning from interactions with advanced contact centers. When skills-based routing, strong use of contextual information, heavy automation, and integration with other business platforms are critical to the success of a contact center, the name of the vendor on the infrastructure is far less important than its ability to support the right mix of features, protocols, media, and application integration needs. Indeed, in many cases these types of contact centers would appear to many to approach their infrastructure selection process less like an infrastructure project and more like an enterprise application project.
And this might be the way that IT should start thinking about what “unified” really means. If it’s just a thing that one buys from a vendor, then it’s hard to push the vendor to expand functionality and support modes of interaction, automation, and integration that are important to the enterprise. It’s even harder to ask the vendors to provide platforms that provide the right mix of flexibility, heterogeneous product mixes, and wide-spread environments that enterprises often must support. And it provides “excuses” for not adopting standards, participating in standards bodies, or allowing enterprises to pursue the technical solutions that best suit their needs.
Obviously, this way of looking at “unified” results in a distinct “unification service” that coordinates multimodal communications and abstracts clients, applications, and endpoints from the actual infrastructure that supports any particular form of interaction. And ultimately, that strikes me as being highly desirable for the enterprise and a more “useful” way of approaching the entire “problem” of UC. Rather than framing the problem tactically around a particular product, it demands strategically focusing not only on what systems can be used, but how those systems should be used throughout the enterprise. That seems to be where our attention needs to be focused to build a business case for a significant investment in new infrastructure.
Category: Unified Communications Tags: UC, UCC, Unified Communications