Social Breathes New Life Into Knowledge Management For Customer Service

Kate Leggett

You have to admit that knowledge management (KM) is hard — it’s hard to explain, hard to implement, hard to do right. It’s not just technology. It is a combination of organizational realignment, process change, and technology combined in the right recipe that is needed to make KM successful. And when it is successful, it delivers real results — reduced handle times, increased agent productivity and first closure rates, better agent consistency, increased customer satisfaction. Check out the case studies on any of the KM vendors' sites to see real statistics. Yet despite these success stories, and despite there being commercially viable KM solutions on the market for over 10 years, I am unsure whether KM really ever crossed the chasm.  

Why is it then that we are seeing renewed interest in KM in 2011? I believe it’s attributed to listening (and acting on) the voice of agents and customers, coupled with loosening the strings of tightly controlled content that has breathed new life into KM. Most common trends include:

  • Using more flexible authoring workflows. In the past, knowledge was authored by editors who were not on the frontlines of customer service, who foreshadowed questions that they thought customers would ask, and who used language that was not consistent with customer-speak. Authored content would go through a review cycle, finally being published days after it was initially authored. Today, many companies are implementing “just-in-time” authoring where agents fielding questions from customers, not backroom editors, create content that is immediately available in draft form to other agents. Content is then evolved based on usage, and most frequently, used content is published to a customer site, making knowledge leaner and more relevant to real-life situations.
Read more

Want Better Quality? Fire Your QA Team.

Mike Gualtieri

Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.

This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.

Why Does This Work?

The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.

As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."

Can This Work For You?

Read more

The Nastiest Performance Bottleneck Is Often The Database

Mike Gualtieri

Some of the most joyful technical challenges I experienced as a developer were solving application performance problems. Isn't it fun. You are Sherlock Holmes - examining the architecture, diving into the code for clues, and scouring through logs files to find the bottlenecks that are responsible for snail's pace. However, this job is a lot harder than Sherlock Holmes or CSI. It is more like Dr. Gregory House, because you are racing against the clock. For every minute of sluggish performance, you could be losing eyeballs and therefore revenue. Worst case: the patient, i.e., your website, dies.

Performance Problems Are Usually Elevated Because Of A Crisis

Your business just launched a Super Bowl commercial that confidently directed people to your website - #fail. More likely, a new release of software performs like a dog (with apologies to Greyhounds) because of lame coding and nonexistent performance testing.

 You Need A Clever Solution, Fast

Read more

The Seven Qualities Of Wildly Desirable Software

Mike Gualtieri

Cosmopolitan magazine certainly doesn't publish articles such as "Seven Hairstyles That Will Make Your Man Yawn." Wildly desirable is more like it. And so too, is it with great software. If you want your applications to be successful, you better make them wildly desirable.

My latest published research has identified seven key qualities that all applications must exhibit to be wildly desirable, with our choices based on research and inquiries on software design and architecture; assessment advisories with clients; and interviews with leading experts, including both practitioners and academics.

Forrester defines the seven qualities of software as:

The common requirements that all software applications must satisfy to be successful: user experience, availability, performance, scalability, adaptability, security, and economy.

Seven Qualities Of Wildly Desirable Apps

All seven qualities are important, but if you get the user experience (UX) wrong, nothing else matters.

The UX is the part of your application that your employees and/or customers see and use daily. You can do an exceptional job on project management, requirements gathering, data management, testing, and coding, but if the user experience is poor, your results still be mediocre — or even a complete failure.

Read more

Release Management And The "First Rule Of Holes"

Jeffrey Hammond

 

Ever hear about the "First Rule of Holes"? It's pretty simple — if you find yourself in a hole with a shovel, the first thing to do is.... stop digging!

That's kind of what it's like in app dev when it comes to release management: We've dug ourselves a pretty deep hole, and it's impacting our overall ability to ship software on time. We recently ran a survey of app dev professionals that confirms what we hear in our client inquiries: Most development leaders are frustrated with slow software delivery and their release management process (see Figure). While Agile speeds software design and development, it doesn't do much to speed up release and deployment — creating a flash point where frequent releases collide with slower release practices.

But some organizations have stopped digging themselves in deeper. They are working with their peers in operations to streamline release management and cutting steps into the side wall of their hole so that they can climb out, step by step. Here are five steps that they are taking:

  1. Investing in improving their pre-build processes. Many problems that occur during a release cycle have their root cause in inadequate pre-build tasks and activities.
  2. Expanding release management throughput. Projects that have large code bases or extensive testing cycles are using parallelism and intelligent testing processes to speed up the early stages of the release cycle.
  3. Optimizing their release pipeline. After taking care of the early stages of the release pipeline, advanced teams are implementing virtualization, parallel testing, and developer self service to further compress their release cycles.
Read more

I Don't Want DevOps. I Want NoOps.

Mike Gualtieri

DevOps is a term used to describe better communication and collaboration between application development professionals and infrastructure operations professionals. "Dev"+"Ops"="DevOps." The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure. I applaud the goal of DevOps to improve the process of deploying application releases.

"No"+"Ops"= "NoOps"

The last thing many application developers want to do is have a sit-down with the ops guys. Besides which, they don't understand. Sure, the ops guys efforts are critical to our applications because they have to run on something. But, developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps. The goal of NoOps is also to improve the process of deploying applications. But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them. Of course, this is not just about getting virtual machine instances. It is also about release management. Ops can run this public, private, or hybrid infrastructure and give developers the tools they need to responsibly deploy applications faster.

Customer Service Myths, Half-Truths, and Total Nonsense....Continued

Kate Leggett

I got a lot of feedback from my last blog post, and I’d like to share my thoughts on each of these statements about customer service. I am sure my point of view is contentious, so please keep comments coming. It will force me to rethink my stance. I’ll cover each of my categories in a separate blog post.

Social Customer Service Myths

 

Myth

My POV

Reason behind my POV

Social CRM is giving customers control

 

Nonsense

Paul Greenberg defines social CRM as the The "company's programmatic response to the customer's control of the conversation." Its about the company taking hold of the reins of the conversation, not the other way round.

Have a look at what Paul Greenberg says here about this topic:  

Twitter works for customer service

Half-Truth

It sometimes does if the answer can be communicated in 140 characters. It shows that you, as a company are listening and acting on comments.

However, instead of engaging in customer service over Twitter, it is often more effective to take the conversation offline to a more suitable communication channel based on the issue at hand and the customer’s channel preference.

Read more

Explained: Java Is A Dead-End For Enterprise Application Development

Mike Gualtieri

Whoa. My post Java Is A Dead-End For Enterprise App Development received record-breaking readership and passionate comments. Thank you for reading, and thank you for your comments. Clearly it hit a nerve. Many of the comments legitimately called for an expansion of my arguments. Fair enough. I have done that in a 50 slide presentation that I delivered as a teleconference on January 24, 2011. Forrester is making this presentation available to download, free to anyone who registers at the site. Registration is free, so please feel free to register and download the presentation. I welcome your comments on the presentation here, at the original post, or on Twitter.

Click here for free registration and to download the Is Java A Dead-End For Enterprise App Development slides.

SAP 2010 - Predictions Review Of A Turnaround Year

Holger Kisker

SAP Has Managed A Turnaround After Léo Apotheker’s Departure

In February 2010, after Léo Apotheker resigned as CEO of SAP, I wrote a blog post with 10 predictions for the company for the remaining year. Although the new leadership mentioned again and again that this step would not have any influence on the company’s strategy, it was clear that further changes would follow, as it doesn’t make any sense to simply replace the CEO and leave everything else as is when problems were obviously growing bigger for the company.

I predicted that the SAP leadership change was just the starting point, the visible tip of an iceberg, with further changes to come. Today, one year later, I want to review these predictions and shed some light on 2010, which has become the “Turnaround Year For SAP.”

The 10 SAP Predictions For 2010 And Their Results (7 proved true / 3 proved wrong)

1. More SAP Board Changes Will Come — TRUE

Read more

Customer service myths, half-truths and nonsense

Kate Leggett

It is often said that managing a call center is more of an art than a science. Some customer service managers use standard operational metrics to manage their business to – like average hold times (AHT), first contact closure rate (FCR) agent, agent productivity numbers, escalation rates, etc. Others apply established customer service best practices to their organizations without understanding the intent behind these best practices. Yet other companies adopt the current trends without an analysis of their strategic importance.

Here is my list of “half truths and total nonsense” about management philosophies and technologies in customer service. Which ones resonate with you? Which ones do you believe are not myths and work for you?

Kate’s List of Common Services and Support Myths

  • Social customer service myths
    • Social CRM is giving customers control
    • Twitter works for customer service
    • I don’t need to interface my social processes with my traditional customer service processes
    • If I have a forum, I don’t need a knowledgebase
  •  Multichannel customer service myths
    • Established best practice apply to my call center
    • I am special - Established best practices do not apply to my call center
    • Front-line support agents don’t know anything
    • When you measure operational activities, you measure business outcomes
    • Support can act independently of brand –Support can have a different brand identity than the rest of the company
    • Email doesn’t work as a support medium
    • Chat won’t work for tech support
    • I dont need proactive chat
Read more