Service Oriented

The best customer service experience in recent memory

I'm pleased to say that last week, to my surprise, I had the best customer service experience I can recall.  And the shocking part - it was AT&T.

That's right.  AT&T. 

First, some background.  I realized recently that I'm paying too much for various internet and phone service - something like $100 / month (without cable).  This plan includes the fastest DSL, unlimited long-distance, preferred rates for international calling, and plenty of Caller Id variations.

I was pretty confident I could save at least $20 / month.

So, I called on a Monday morning on my way to work.  The IVR system asked what number I was calling about, so I made sure to enter that.  I waited 35 minutes or so on hold (the rest of my commute) - and hung up.  I tried again later in the week - to no avail - another 20 minutes on hold.

Finally, last Thursday night, I called again.

The IVR system asked, "I see you've called recently about this telephone number.  Has your issue been resolved?"  I responded no, or more literally pressing the number "2". 

(Parenthetically, this seems like a good way to get someone's attention - call and hang up twice.  My wife finds it effective when calling me.)

Here's where the experience gets good.

Amy, an AT&T customer service rep, gets on the line.  And she's fantastic.  It's almost like the IVR knew to route me to one of their better customer service people.  

Amy runs the numbers a few ways and helps me get the lowest price she can.

So, I'm ok with the $20/month savings and I ask, "Is there anything more we can do to make this less expensive?"

She answers, "You've been a loyal customer for 11 years.  I'll tell you that people who cancel are offered 50% off their DSL for six months."  In moments, I was connected to the cancellation department, to a fellow named Henry.

Then something dreadful happened.

Henry, in cancellations, was starting from the top of the call script.  That's right, you heard me.  The TOP of the call script.  Ugh!

I was about to have to go through everything all over again.

And then, at the pit of call center despair, something unheard of happened.

Amy, who was spying on the line, dropped Henry from the call.  She swooped into my phone call and saved me from 20 minutes of wasted time.  She apologized for the mixup, and connected me with someone who understood the situation and followed through on the promise to offer me a discount in the face of a potential cancellation.

I've got two takeaways from this encounter:

1. AT&T could do better as a whole on this - like offering a deeper discount for this kind of loyalty.  I still think the best way to keep people on is to say, "We're committed to helping you spend the least money for your needs so you stay with us."

2. Amy is the real heroine of our story - someone customer-focused enough that, even at the end of her shift, took the time to follow through and make sure the customer she helped made it to the end of the call with a positive experience.

Kudos, Amy!  You're a rockstar!

Watch your prepositions

About 10 years ago, I was working at HP as a Software Engineer while a friend of mine worked in the Education and Training department.   I recall her speaking highly of a class that she recently had taken.

The key take-away was about prepositions - use "and", not "but".  This lesson is especially useful in brainstorming contexts.

Using the word "but" indicates, "I'm about to slow the conversation down.  I'm about to raise a concern.  I'm about to hold things up."  The word "and", on the other hand, signals "I'm going to build on what you've expressed.  I'm going to speed things along.  I'm going to propel your ideas forward."

It's an enormous difference - and it's significant to those around you.  In providing services to our enterprise customers, using the "and" more than the "but" can make all the difference in perception.  Are we part of the solution?  Or part of the problem? 

Personally, I grew up in an environment that valued the "but"s - the objections, the analysis.  I can't say I've entirely rid myself of that critical voice - in fact, I still believe that on the whole, it makes ideas better, sharper, and stronger.

But (and I do mean, "but" here), I think the "and" is powerful as well, and often can lead to strong outcomes as well.  There are many times that I've seen people get behind an idea and steer it toward success.

I bore a telling smile this morning during carpool, when I heard the "brainstorming" of my 6-year old daughter and her carpoolmate as they invented a fabulous scenario.

Child 1: "And there would be a really big house for all our friends..."
Child 2: "AND, we could have their whole families be at the house...."
Child 1: "AND, everyone could have their own room, if they wanted one...."
Child 2: "AND there would be a big pool with a slide..."
Child 1: "AND every family could have its own pool...."

I hope that the early use of the word "and" will lead to a lifetime of positive solution building (but not run-on sentences).

The Long Tail...

After over a lengthy hiatus, it's great to be back in the blogosphere - and I'm looking forward to your feedback on the ideas presented here.

Today's topic: the long tail.

In modern business contexts, The Long Tail often refers to the tail of a Pareto Distribution.   Wikipedia attributes Wired Magazine's Anderson with using this term to describe niche business strategies that sell "less of more".

Personally, I use The Long Tail in a product-lifecycle context - it's the tail of work that follows the decision for every incremental change in the product or service offering.  The Long Tail of work can include documentation revisions, QA test revisions (can be major), QA efforts, releases (maybe more than one), and other activities.

First, a non-software example.  I recently had the opportunity to chat with a Development Director at a non-profit private school.  She explained that the school planned to replace the website soon.  As it turns out, she hoped to replace not only the brochure-ware site, but planned to add significantly to the site's functionality.  Vendors in the educational space offer functionality that allows teachers to post homework assignments for parents' review.  The Development Director thought this would be a great service for the parents, and would reflect positively on the school.

So, I asked the Development Director - "Who will be accountable for getting the homework up on the site?"  "The teachers," she responded.  "Really?"  I asked with a bit of incredulity in my voice.  She admitted, "Some of the less-tech-saavy teachers might ask me to do it."  "And if you were to leave your position here at the school, who would do it then?"  I queried with evenness in my tone.   

She exhaled.  It was then obvious that trailing behind this great idea was a long tail of work - starting with the implementation of the product and continuing through its operation into the indefinite future.

In our world of software development, we often have difficulty assessing the impact - the pile of work that falls out of a single feature request - but it's there and it needs to be managed. 

Sometimes, the best approach to handling this kind of a request might be considering the impact of not implementing the feature change.

So - beware of the long tail of an innocuous-looking request.

Ultimately, if you're careless about it, you might find yourself in an infinite loop (see, If You Give a Mouse a Cookie).

How do you manage The Long Tail?

training = (what we should have delivered) - (what we delivered)

It's a simple equation. Training is often the gap in design between what we deliver and what we should have delivered.

Had we started a project armed with the knowledge that eventually resulted in the gap, we would have delivered something more, and it would have cost more. That gap - or that cost - has to be covered by someone, somehow.

This scenario plays out at the end of a project, when someone on the team astutely points out that there's a use case that was missed during the early stages of the project. An engineer often responds with a "work-around", which is then incorporated into the training (as though that's how it was originally designed!).

So, the training spans the gap - between what we should have done, and what we did.

When someone's about to say, "Let's just add it to the training," what's going through her head? How does she make that decision?

I can think of at least a few expressions that are evaluated in the mind of the decision maker:

• Additional training costs - in dollars, how much will it cost to modify the training?
• Cost Overrun - in dollars, how much will the changes to the system cost? how much will the additionaly QA and documentation efforts cost?
• Schedule Overrun- in dollars, how much can we estimate the delay in shipping the system will cost us? Lost efficiencies? Lost customers?
• User Cost - in dollars, how much will this cost our users? how will it affect them? what's the true cost of shipping an imperfect feature?

I've sorted these variables in order of decreasing certainty - usually you can easily estimate the change in training costs with a high degree of confidence, and the cost/schedule impact with a little more variance, and finally the user costs primarily by licking your finger and holding it up in the wind.

The decision maker should try to strike the balance between these variables - after all, if the estimated User Cost is sufficiently high, changes are made to the application. If, however, the cost to the user is estimated to be low, then the user pays (every time) for the change that was NOT made.

Since there's a gap, it's really only a question of how you distribute this cost - who pays?

As it turns out, there's one more expression that folks likely consider - what is the personal cost to me about shipping late and overbudget? And remind me, how many others can share that cost if I ship on time by incorporating it into the training?

There it is - the full-employment theorem for training writers. There will always be gaps in projects, that, all-too-often, will often be addressed through training.

What to do when your engineering team tells you a UI sucks

It feels like eons have passed since I've had the opportunity to share a few thoughts. So I might be a bit rusty - so please be forgiving.

In a recent encounter with a client, an engineer on the team (an employee at our client) confided that he believes that the user-interface for the product he develops and supports has opportunities for improvement. Or, perhaps more succinctly (and true to the actual quote), "The UI sucks."

First, let's face facts. Many, many, many UIs suck. Those that don't are exceptional. In this entry, I'd like to focus what you can do once your engineering team expresses their distaste for your UI.

Step 1: Acknowledge the facts. Accept it - they might be right! Be open with the engineering team that has noted and communicated its concern over the user-interface. Unlike years ago, when engineers blamed users, today's generation of engineers are becoming more user-interface saavy. As users themselves, they find inaccessible user interfaces to be frustrating. Acknowledging the truth helps.
Step 2: Get details on the areas that suck most. Usually, when your engineers take issue with something, you can get to specifics. Sure, there's an occasional debate that appears purely philosophical, but they certainly respect the concept of giving you the data. Ask for the exact use cases in which the UI sucks. Ask them what specifically about the interactions are sucky. It's not like high school - in the working world, you can't claim something sucks, and then not back up your claim.
Step 3: Get their input. There certainly are people in the world who identify problems but don't have solutions - engineers usually aren't those people. They do find problems - but they almost always have ideas on how to solve them. Ask for their ideas. Dig deeper - ask them why they think their suggestions will make the user interface better.
Step 4: Understand how it affects them. Sure, your engineers aren't your users, but they exercise your product as often as some of your users. After all, they write code - and then they test like mad (hopefully). A poorly-designed UI can be demoralizing for the engineer trying to test a scenario that requires countless clicks and graphical manipulation. Believe it or not, your engineers really are your users, too! Step 5: Make sure that the conceptual model is still intact. Problems with your conceptual model - or its traction with your engineering team - are often at the root of the awful UI conversation. In designing any product, there's a conceptual model in play. For example, an automobile offers controls that influence the behavior of the car. There are switches, wheels, pedals, and shifters. Each of these UI controls affects the behavior of the vehicle. As a driver, I don't need to understand the number of cylinders in the engine (if it has cylinders at all), but I do expect that pressing on the accelerator makes the car go faster.
Sometimes, in the process of implementing a design, a team loses track of the conceptual model, and starts focusing on the details of their implementation. Then, they struggle to understand why the UI doesn't reflect the implementation! This skew - or losing track of the conceptual model - is one of the primary reasons projects go off-track, and why development efforts take longer than expected.

Once you've got everyone back on the page, you'll be able to make a better assessment as to next steps. Most likely it will be to continue the course of action, plan some solid user testing, and expect to fold in the changes in a future release.

And in the future, ask your engineers what they think of the UI. You don't have to listen, but it might help. You never know.

What's in a name?

I'm sure you've heard this one before.
Names matter. Yep, they do.

I was at a friend's baby-naming yesterday, and I wished a congratulations to one of the proud grandparents. I complimented him on his new granddaughter's name, "It's really lovely," I remarked. His response conveyed his disappointment - "I'm sure my son spent countless nights thinking up that one!"

But names matter not only to people - they matter to projects, too. Bad names can make projects difficult, and good names can keep projects on time.

Recently, I was working with Pete on a project for a client. As it turns out, the scope of the project was straightforward - integrating a new search engine for searching resumes. Simple, right?

What made matters confusing rather quickly was that our client didn't really have a pre-existing notion of searching resumes to retrieve resumes. In truth they were searching for candidates by searching the text of resumes. The resume was an attribute (or child) or the candidate. The proof that they were searching for candidates was how the results were retrieved - the data displayed included candidate data - NOT resume data.

What's the difference between candidate data and resume data?

Candidate data includes things like names, addresses, years of experience. In some senses, it's the fully-parsed, fielded version of the resume (with some extra goodies - like how these candidates relate to your staffing business, to boot). Resume data, in unparsed format, also can include some metadata, like name of resume, date submitted, and length of resume, but can't really have all of the fielded data of the resume.

It's just semantics, right?

Not quite. In the course of many projects, the definitions of entities and the underlying assumptions evolve. These changes - often quite subtle - can lead your team and project down endless rat-holes. You'll find yourself struggling with meanings, revisiting terms, clarifying misunderstandings. It can be unending.

I don't think I can stress this enough - poor name selection can lead to hours and hours of wasted cycles.

So, what did we do to confront this terminology skew?

1. Confirmed our understanding.We spoke to the business analyst and tech lead and reviewed the kickoff materials, proposal, and early conversations. We also identified the issue and made sure we were all "feeling it".
2. Escalated to the sponsor. During our weekly status meeting, we spoke to the sponsor and he reiterated we were correct in our understanding.
   
3. Renamed our entities. We spent the extra hour or two resetting our terminology to the more limited words. We're confident that choosing words that are more narrow will better convey the current state of the system. When the definitions broaden, we'll let someone else refactor and rename.

It's sometimes hard to believe that names can make a difference - but they really can.

Believe it or not, your software is bureucratic, too

How many times have you said, "Well, first do x, then y, then z" as opposed to cutting to the chase?
How about a system where you've got an EJB, delegate, bean, hibernate, and database? Is that not a bureacracy?
Comes back to what's globally acceptable!
One-offs are bad - patterns, conventions, norms are good. They make things easy to understand - and that's a big deal.
"Becoming socialized" means learning what's cool and what's not - varies by organization and culture.

Bureacracy Evolved

Unlike real gov't bureacracy, what if we continually rengineered bureacracy - inputs and outputs needed to be the same (or evolve slowly and in a user-friendly way)

Be a good citizen - provide opaque and transparent implementations

Ever find yourself working with a third-party library and wishing you could mock it up?

Of course you have.

Seems simple enough when you get started, right?

First, it's just mocking an Engine,Factory or Connection object, but before you know it, you've got piles of mock classes you've had to implement to exercise your code without the actual third-party library connected.

What makes matters worse, is that the third-party library you're working may not have interfaces on all of those objects! No worries, I'm sure you've found a work around - maybe you use dynamic proxying to get around that?

Perhaps this was a silly idea to begin with - maybe we should have simply trusted the third-party code? Well, it may not be an issue of trust - it may be simply impractical to be able to control the state of the third-party code - or the data that back it.

Ok, so let's return to mocking the object up.

I'm sure you'd agree that, in essence, we're building a second implementation that we hope conforms to the way the true object should be used. Calling conventions, initializations, setting up - our mock objects should act like the real ones, so we'll need to understand the third-party app pretty darn well to make sure we get it right. In fact, it's highly likely that we'll be using the real code first, and later retrofitting with this mock object. Lovely. So much for test driven development. Sigh.

And this second implementation we're building - it's an odd one at best. It's going to need to give back the same data quite frequently. It'll also need to simulate error conditions and states. But we're supposed to vouch for it. We're supposed to read the docs and write code that effectively simulates the code the third-party published. We are saddled with the responsibility of intimately understanding the third-party implementation and emulating it.

Why on earth would we want to do that?

What if the third-party vendor also shipped a *transparent* implementation - one that's consistent with your conceptual model of how the third-party library works?

When you study an API, you build a conceptual model in your head of how the API is implemented. It may not be exactly how the actual API is implemented, but it's usually good enough.

For example, when you see a method like:
String lookupLastName(int employeeId);
You think, "There's a way to do that - worst-case, iterate over all employees, and check the employeeId, then return last name. Best case, hash-map of ids." In truth, it could be that a database is read, or that a remote service is invoked. But you don't care. It's pretty sensible to you. And you know it wouldn't take much to build a mocked-up version of that API. Neither for you, nor for the supplier of that third-party library.

When we write a mock, we hard-code, or follow a record/playback model. Either way, we interpret the third-party API, and reimplement it ourselves.

If the third-party wrote the mock, they might build it backed by a flat file. For example, an implementation of an ORM tool might speak to a CSV file. A B2B exchange that read XML messages out of directories.

If they delivered a transparent implementation alongside their opaque implementation, they could give customers an implementation that is consistent with the conceptual model of your code - and consistent with the opaque implementation.

But wait, it gets better.

If you're the third-party, your test code should work for both the opaque library and for the transparent library.

And, if you're the consumer of the third-party library, your code should with them both as well.

Why not build and ship both opaque and transparent implementations?

Ahh, the Benefits of Bureacracy

It's true, there are plenty of benefits to bureaucracies.

And bureaucracies can't function without bureaucrats - whom we can all admit are, in fact, generally underappreciated. On average, bureaucrats are valued less than Mothers or Bosses, if having a Hallmark Holiday is any indication. So far, there's no "Bureaucrat's Day" - but don't rule it out forever!

As it turns out, though, it's not the bureaucrat that should be appreciated. After all, the bureaucrat does not create bureaucracy - the bureaucrat is merely the soldier, the desk jockey, the customer service rep - a piece of the broad bureacratic implementation.

Then to whom shall we pay homage to for creating bureaucracies?

To governing bodies - be they individuals, groups, or institutions themselves.

Why should we appreciate these enormous, intransigent, complex, hard-wired, cult-like entities? What makes them great?

Because in their weighty existence, they provide tangible benefits:

• Standardize processes


• Standard outputs and inputs (forms usually)


• Rigidly define "how things work"


• Operate predictably (minimal change)

Bureaucracies are very efficient at enforcing standards. They create often massive barriers to violating formalized processes. Bureaucracies in Corporate America tend to revolve around business objectives:

• Controlling money


• Controlling time


• Controlling quality


• Controlling data


• Controlling access

Bureaucracies - are - on the whole, good. And that's the part that's hard to appreciate as individuals.

The bureaucracy places the needs of the whole over the needs of the individual. There is, invariably, a more efficient way to get from Point A to Point B for the individual, but for the sake of society, we organize a safe means (perhaps slower for the individual) to move from A to B.

So, how is it that we hate bureaucracies in the face of such great benefits?

Well, as it turns out, they're never right.

• When we need to break the rules... When it's time to make a break with standard operating procedure, bureaucracies are our most daunting foes. Escalation after escalation, there often appears to be no one who has the authority to resolve the issue at hand. Put another way, we need to amend the rules, but no one knows how!
  
  


• When we follow the rules... When we're following the standard operating procedure, sometimes we have to do a lot of repetitive work, but we don't understand why (examples include filling out multiple forms with the same information). This is an exceptionally frustrating situation. It's almost as though we are sucked in to the bureaucracy itself!
  
  

So, how can we reap the benefits of the bureaucracy without the agony of the situations above?

to be continued