Archive for the ‘Customer’ Category

How to lose a customer, in 1 easy step

Monday, May 11th, 2009

Finding new customers is hard.  First, you have to identify the people who are interested in what you are selling.  Then you have to find a way to meet those people so you can tell them about what you are selling.  Then you have to convince them that they want what you are selling, and if you manage to do all that, you still have to agree to a price for everything.

Doing that takes time, money, and a whole lot of effort and patience.

On the other hand, if someone is already a customer of yours, things become much easier.  You already know who they are and what they want.  They already know you and (hopefully) trust you and want to purchase your product or service.  So all that’s left is to agree on a price – which should be easy because they already have some expectation based on their previous purchase.

Given that keeping an existing customer is so much easier than finding a new one, you would think that companies would work hard to make sure that their existing customers stay customers.

Sometimes companies keep customers (either intentionally or not) through “lock-in” – they make it so difficult to switch to a competitor that it isn’t worth the cost.  This is essentially why Microsoft dominates the business world.  The cost of switching is too high for most companies – they simply can’t do what they need to do on other platforms (or they don’t know how).  Comcast keeps its customers despite horrible services, prices, and policies because in most cases they are the only option for cable or high speed internet.

So how do you keep a customer if there are low barriers to switching or lots of competition?

You can try to create “brand loyalty”.  By creating a community around the product or company, you can convince people to keep coming back.  This is (more or less) what Apple relies on.  You can also create loyalty through exceptional customer service.  HP support managed this when they promptly and efficiently fixed my out-of-warranty laptop for free.  REI does this through their simple and generous return policy (if it breaks or you don’t like it – return it).

If none of these options are possible, you are left to compete on price, and if you are competing on price you better price yourself accordingly.

Take for example, my webhosting provider.  I use webhost4life.  They have been OK – they have had several service outages and issues with my site, but on the whole I’ve been satisfied with their service over the past year.  Being inherently lazy, I decided to renew my plan, and look into adding a second site for my photography work.  Imagine my shock when I discover that they wanted to charge me for the privilege of renewing my plan.  Since all the work in setting up the hosting plan had already been done, essentially they are trying to charge me for taking my money.  To add insult to injury, if you sign up for a new account with them, they will not charge a setup fee – so it is cheaper to be a new customer than an existing one, yet somehow they expect me to feel some compulsion to continue purchasing their service.

Not going to happen.

They are competing on price, and there is a lot of competition out there.  The cost of switching is roughly one hours worth of work – most of which doesn’t even require my attention (uploading and downloading the site).  They are a company that didn’t realize how they were competing, and as a result lost customer.

Posted in Customer, Website | Comments Off

Erecting Barriers

Thursday, April 9th, 2009

I am often surprised at how difficult it can be to give other people your money.  Too many sales departments in companies providing business services seem to be under the unfortunate impression that their software/service is *so* compelling, that it can dictate the terms of the conversation.  They erect barriers so they can control the sale process and prevent simple comparisons.  By controlling the terms and content of the sales and marketing process, they believe that they can maximize the sale.  Of course, they all claim to do this to ensure that their potential customers “understand” their choices and “select the option that provides the best value”.

Unfortunately, I have yet to encounter a piece of software or a business-related service that is so compelling that I will not walk away from it if I cannot control the terms of the sales process.  As someone who is frequently asked to make purchasing decisions, I have dealt with a wide spectrum of approaches to sales and have discovered a number of common barriers that will almost immediately cause me to look elsewhere.

  1. No up-front pricing.
    If you can’t tell me how much your product will cost, I can’t tell you how much I will pay so don’t ask me how much money I have budgeted.  When asked, I will generally lie to you and expect that you are lying to me.  Your base price should be posted on your website.  If I have to work to find your price, I will assume it is over my budget.
  2. Sales Inquiries do not *require* anything.
    If I try to submit a sales inquiry on your website, you should accept it.  If I don’t want to give you my phone number, use my email address.  If I don’t want to tell you where I heard about you, just be thankful I found you.  It is not my job to sell myself your product.  All I want to know is if it will meet my needs and you don’t need to know where I am located to tell me if your package can work with WordPerfect documents.  If your contact form bounces back to me, I’m not liable to try again.
  3. I am more than capable of selecting the “best” option.
    I don’t need your help unless I ask for it.  If I ask for it, it usually means you failed somewhere, so you better work twice as hard to answer my questions.  I do not need to spend an hour on the phone taking a survey about my problem.  I know my problem.  What I want to know is how you will solve it, and if I have to spend longer than 5 minutes figuring that out, I won’t.
  4. Contact must be done on my terms.
    Making these decisions is a very small part of my overall responsibilities.  It is not my job to listen to your sales pitch.  Give me a variety of ways to contact you and make yourselves available on my schedule.  Do not take my contact information and contact me on your schedule.  Just because your contact form demanded my phone number does not give you the right to use it.  Besides, I probably used a fake one anyway.

I have found that companies that use these barriers generally do so because of a lack of confidence in their product.  They usually have a number of close competitors and they are afraid of making the process transparent because they believe it will give their competitors an edge.  This may be true, but it is not my problem.  All it indicates to me is that your product or service is not as compelling as you want me to believe.  If it was, you wouldn’t be worried about your competitors because your product or service would stand on its own merits, and a product or service that can do that is always the best option.

Posted in Customer, General | Comments Off

HP Support – Take 2

Friday, March 27th, 2009

I’ve been without a laptop this week.? Given that I normally use my laptop for writing and free-time coding, I decided to take the opportunity to catch up on some of my outside interests.

Unfortunately, HP had a different idea for me.

I mentioned in my last post the wireless and display failure that was plaguing my laptop and eventually forced me to return it for service.? After its wireless connection stopped working, I submitted the problem report to HP.? Within an hour they had authorized a return shipment and agreed to fix the additional display problem, all at no cost to me, despite the laptop being out-of-warranty.? The next day I received the box to return the laptop for service.? I still needed to image my disk (since I had some sensitive data on it) and then restore it to “factory-condition” using the original restore disks.? I did this over the weekend.? I wasn’t in a real hurry since I figured the laptop would be gone for over a week anyway.

Finally, on Wednesday I packaged it up and dropped it off at FedEx over lunch.? 2 days later the laptop is back in my hands, the display is fixed and the wireless card appears to be restored.

So much for my free time…? Thanks HP, thanks a lot (no seriously, I mean it!)

With the quality of most customer service departments leaving much to be desired, I thought I would highlight one of the few technical companies that seems to have done it right.? I don’t know if I was fortunate to get such a helpful customer service agent, but I hope that they continue treating their customers with this kind of respect and efficiency.

Posted in Customer, General | Comments Off

HP Support and FizzBin

Tuesday, March 17th, 2009

In an amusing coincidence, I stumbled across Scott Hanselman’s posting “FizzBin: The Technical Support Secret Handshake” today, right after the wireless card in my laptop died (fortunately, my desktop is alive and kicking, and the wired NIC is still working just fine in the laptop).? I wholeheartedly agree with his sentiment.? I have lost far to much time explaining that I did in fact follow all the suggested procedures in the support manual before contacting them.

This is why I dread dealing with support – to the point that I actively avoid it.? This same laptop (an HP Pavilion dv9208nr – because Pavilion is too easy to remember apparently), has also fallen victim to the left hinge display problem.? My hinge has been busted for a long time now, it actually doesn’t bother me that much, but they sent me a note admitting they had a problem, which is always the first step.? So I looked into it, and it required contacting support and giving up my laptop for up to 2 weeks.? Since the hinge just didn’t bother me, and I use the laptop daily, it was really a non-starter for me.

Then my wireless died.? That of course I cannot have.? It rather defeats the whole purpose of the laptop.? I tried everything I could think of, but nothing worked.? I updated everything and it made no difference.? From the computer’s standpoint, the wireless card no long existed.? This was unacceptable, so I bit the bullet and submitted a support request.? Since I was working, I went on the HP support website and submitted an email request.? The form was fairly standard, except that it had a drop-down that let me specify my technical ability.? I explained what happened, what I had done, and indicated that I had a high technical ability.

Within 30 minutes I had gotten an email back from a support technician agreeing to service the laptop free of charge.

I don’t know if this is a common problem with this laptop (a quick search turned up no real likely candidates for my model) and that was why they quickly agreed to an *out-of-warranty* (did I mention this laptop’s warranty expired almost a full year ago?) laptop, or if they simply acted in good faith to correct the problem, but either way I was impressed.?

I don’t know if my indication of technical ability had anything to do with it, but I must admit that I prefer this interaction to having to invoke the FizzBin code…? No fuss, no arguing about whether the problem was with my router, just a simple thank you and an offer to fix my problem.

Posted in Customer, General | Comments Off

Doing the right thing, despite your customer.

Monday, March 9th, 2009

It seems to be pretty accepted in the software world the you should not give your customer what they ask for, because they don’t know what they want.

Of course I’m exaggerating slightly – this is all a semantic subtlety that hinges on the idea that you discover what your customers “need”, not what they want.? Unfortunately, this clever wordplay is lost on many developers and every customer (real or imagined) I’ve ever met.? If you are developing commercial software, you certainly have the ability to decide what you will and will not do.? More often than not though, even commercial software has one or two customers that are large enough to demand the type of attention normally reserved for custom software, and if the development is being paid for by a customer, it becomes even more difficult.? So how do you explain to these customers that despite the sheer brilliance of their request, you are actually going to do something else entirely, and by golly they are going to love it even more??

1. Be Honest and Trustworthy

This one should be obvious, but so many people miss it in their desire for profits, success, or simple laziness.? If your customer can’t trust what you say and you can’t be honest with your customers than there really isn’t any point.? No matter what you do, your customers won’t like it, and you will always struggle to understand them.? This does not mean that you must air all your dirty laundry but if you can’t do something because of a mistake in the initial design, admit the mistake and work to correct it.? Your customers want you to improve and be better because it provides direct benefit to them.? Seek out those opportunities and your customers will recognize that and reward it.?

2. Understand Their Request

This is the step that most folks have fixated on.? Understanding the request means more than a simple literal understanding of how to implement the feature exactly as suggested.? Instead, try to understand the problem they are attempting to solve with this feature.? Are they suggesting a new feature because the existing ones are too difficult?? Is there an equivalent way to solve the same problem using the existing feature set?

Of course sometimes the customer simply wants what they want, and it is important to understand that to.? Sometimes a duck is simply a duck.

3. Acknowledge Their Need

This goes hand in hand with step #2.? By taking the time and effort to actually understand their request, you are signaling to them that they are important.? By working with them to help define their need you are acknowledging that they have a legitimate problem that they need solved.

If you don’t care about solving this particular need of the customer, then it will never get solved.? This may be a legitimate outcome.? Sometimes the cost of solving a problem outweigh the gain that could be had, and sometimes the problem is so far outside the bounds of the system that it simply doesn’t make sense.? In these situations, you must rely on the trust you have built up and simply explain this to the customer.? I have even been known to suggest competing alternatives that would address their needs.?

The important thing to remember is that even if you do not want to address this particular problem, it is still a problem for your customer, and they will attempt to solve it no matter what you do.? Ignoring potential solutions because they won’t result in an improvement to your bottom line is a lost opportunity to build up the trust from step #1.?

4. Outline the Cost of the Idea

Since your customers are unlikely to have access to your codebase, they don’t have the information needed to accurately evaluate a given request.? Instead they make assumptions based on their own experiences and needs.? They do not consider everything that needs to be addressed to implement a new feature.? Often times, simply explaining what a feature would cost is enough to dissuade them from a literal interpretation of their request.? It is amazing how flexible a customer can become when faced with a 10 month timeline for a problem they need solved next week.

Of course, this is often abused by the less scrupulous as a customer control mechanism.? If you begin to inflate the cost of ideas you don’t like and deflate the cost of those you do, eventually you will be caught out.? When that happens, the loss of all the goodwill built up by your efforts in step #1 will severely hamper, if not cripple, your future efforts on the project.

5. Suggest Alternatives

Often customers will suggest the first idea that pops into their head.? It is part of your job to suggest alternatives.? Most problems can be addressed in multiple ways, so take some time to consider them.? Figure out the benefits and drawbacks of each approach.? Determine the relative costs of the approaches.? Arm the customer with as much information as possible so they can make the most informed decision possible.? Be careful not to use this step to overwhelm the customer with technical questions and alternatives they don’t care about.? Focus on the problem and how it could be solved, and do not neglect ways to solve the problem using the existing feature set.? Often times the existing features are sufficient, but the customer is unaware of them or doesn’t understand how to use them.

6. Accept the Outcome

Whatever is finally decided, you should accept it.? Holding a grudge because the customer overruled you will simply hurt the quality of your work.? The purpose of these steps is to vet the feature request in such a way that by the time you reach this stage, everyone should understand what is being done and why it is being done.? If you still cannot agree or accept the outcome, you should probably revisit step #3.? It may be possible that the problem is simply something you don’t want to solve.

Posted in Customer, General, Process | Comments Off

Are you sure you want to exit?

Tuesday, December 30th, 2008

Why is it necessary to make me confirm every action I take?? Every time I see a dialog asking me to confirm something, I inevitably just hit return or click through the dialog without thinking, so what is the point?? On top of that, I am now trained to click through dialogs, so on the rare occasion where the dialog is useful (the Unsaved Changes dialog is always useful, even if it can be annoying sometimes), Often I’ll click through without paying attention.

This is bad.

Software should be written so I don’t have to confirm things.? If I screw up, I won’t realize it until after I’ve confirmed the operation anyway, so why not just provide me a way to undo my change so I can get back to my previous state.

Save the confirmation dialogs for things that are irreversible, like closing a document that has unsaved changes.? If you assume your users are idiots, I guarantee you will have idiots for users.? Treat them like they know what they are doing, but provide a safety net for when they make a mistake, and your users will be empowered to learn things for themselves.

Posted in Best Practices, Customer | Comments Off

Appearing Gracious

Tuesday, December 23rd, 2008

No one likes rejection.? Most of us, when faced with it, would rather blame someone else for the failure, instead of looking at what we did to contribute to it.? Seth Godin posits that the responses fall into one of two categories (paraphrased for simplicity):

  1. Throw a fit.
  2. Thank everyone for their time and seek to improve.

I highly recommend you read and think about what he is saying, because it is excellent advice that isn't followed often enough.? But, as with all things, there is a catch.? It is far more difficult than it can seem.? It is not enough to simply go through the motions and appear to be gracious.? You have to actually believe it.? Otherwise, the loss of trust could be so great as to be far more destructive than simply throwing a fit in the first place (at least everyone will know where you stand and what you think).

Fortunately, you can learn to respond graciously, but it take practice, effort, and a sincere desire to do so.? You also need an organization in place around you that allows for graciousness – failure happens, especially in the software world, and if you are not in a place where you can deal constructively with that failure and apply it to your future work, then you will find it very difficult to be successful.

Posted in Best Practices, Customer, General | Comments Off

Solutions are not Requirements

Thursday, December 11th, 2008

Yesterday, I described a particularly prolonged form of Project Suicide.? In my description, I touched on a point that I feel should be expanded upon.? Essentially the type of project suicide that I described revolves around the difference between how a client views a requirement and how most software engineers view requirements.

Clients inevitably frame requirements in terms of a problem:?

I need to be able to add 2 numbers.

Engineers inevitably frame requirements in terms of the solution:

We will provide 2 text entry dialogs.? In each dialog, the user will be able to enter a single number.? We will provide a single button called 'Add', which when pressed will add the 2 numbers in each dialog and display the result in a third text dialog.? The third text dialog will not be editable.

These are 2 very different beasts.? Most engineers will look at the first statement and immediately begin complaining about the lack of specifics.?

  • How do you add the numbers??
  • Where do you enter them??
  • Where do you display the result?

Eventually they will derive out the second example, and set it down as the official requirement, completely losing the fact that all the customer wanted was a way to add 2 numbers.? Everything else is just implementation details of a particular solution.

The problem with treating solutions as requirements is that you remove your ability to address the core problem.? You cannot anticipate future problems, because you are essentially reading from a script that tells you exactly what to implement.? That is not to say that you shouldn't explicitly detail your solution.? It simply means that your solution is not the requirement, it is simply a mechanism to satisfy the requirement.?

Solutions are not requirements.

Don't even bother phrasing a solution as a requirement.? Understand the solution and why it was suggested.? Document the underlying problem that is solved by the solution.? That is your requirement.?

Detail the solution in a design document for the requirement.? That way, no one will be tempted to treat it as gospel.? Designs are changed, modified, even thrown out, and people do not bat an eyelid.? But attempt to change a requirement, and everyone gets upset.

The other advantage of avoiding the temptation to treat solutions as requirements and treating them as designs instead is that on quality development teams most designs will go through some sort of vetting process.? This could be a formal sit down review, or a quick peer collaboration to make sure that nothing is missed.? Requirements rarely achieve even that level of scrutiny simply because by their nature there is little to debate.? They are coming in from the customer.? If the customer wants his spreadsheet software to also control his coffee pot, then at the end of the day the spreadsheet software will control his coffee pot.? This will happen one way or another, so there is little point in reviewing it internally.

Dealing with these vague requirements with multiple possible solutions will initially be a little bit overwhelming if you are used to the tightly constrained world of solutions as requirements.? But with time and effort I think you will find that the flexibility it offers you to address the core problem, not simply implement an attempted solution, will result in a much more satisfying, successful development cycle, and a happier client base to boot.

Posted in Best Practices, Customer, Development, Process | Comments Off

Project Suicide

Wednesday, December 10th, 2008

Have you ever had an argument with a client where you resorted to telling them they got exactly what they asked for?? Out of all the forms of project suicide I have seen, it astounds me that not only is this still common, but it is believed to be a legitimate response to customer's complaints.

The problem seems to stem from this mindset of software engineers to think in terms of solutions – not in terms of problems.? Customers and clients tend to think in terms of problems – they may suggest solutions, but they are limited by the current behavior and appearance of their toolset.? We as engineers like to take these suggested solutions and set them in stone.? We want to write them down and examine their every detail.? We try to force the customer to commit to design decisions so that we can move forward with our implementation.? The customer, who doesn't think in terms of solutions, simply goes with the flow, gratified that his or her suggestion was so useful.

This is why, after spending weeks ironing out the exact layout and specification of the entire feature and then an additional month implementing it, followed by weeks of testing, when the customer finally gets their hands on the release with the shiny new solution, she hates it.? So she comes yelling and screaming to the team demanding you correct your mistake, but of course, the team is protected.? Every step of the way, you've gotten the customer's signature that says this is what she wants.? It is part of the process we are all taught and follow blindly – when in doubt, ask.?

So when she comes yelling and screaming, you pull out all of those approvals and proceed to explain how you did exactly what she wanted.? As a matter of fact, you prove to her that you gave her more than she wanted.? When you are finished, all she can do is tell you to fix it and wait for the next release to see if you have a solution to her real problem.

That is project suicide.

From this moment on, the working environment is changed.? Everything must be documented, approvals must be given, and all decisions must be effectively supported.? Once this line has been crossed, you are no longer working with your clients as a team, you are working as an obstacle that must be dealt with.? The trust has been broken.? The client hired you to solve a problem, not satisfy a process.? Once you are in the business of satisfying a process, your margin for error has disappeared, because the process specifies exactly what is expected, and no allowances can be made.

It always seemed much better to accept the short term consequences of an honest mistake than the long term consequences of a refusal to accept it.

Posted in Best Practices, Customer, Process | Comments Off

Ask the Client

Sunday, August 24th, 2008

Jim has a problem.? He's been tasked to write this new feature which will require him to store a good amount of data on disk for later use.? Speed and scalability are not critical, as the client doesn't believe the storage requirements will grow beyond current estimates.? Suzie, of course, believes that Jim should store all the data in a database because it will make things better down the road if and when things change.? Bill is adamant that this all overkill and he sees no reason to store the data in anything other than a simple text file, thank you very much.? Why fix a problem that doesn't exist yet?? Karen doesn't really care what Jim does, she just wants Jim to hurry up and finish the interface so she can start working on the analyzer code she's been tasked with.

After several meetings attempting to hash out a workable compromise, everyone finally agrees on a resolution – ask the client what she wants.? Whatever the client picks, that is what Jim will implement.? The developers all believe they have reached a perfect solution – not only will they finally get an answer, but they are involving the client in important decisions.

Sometimes asking the client can be the right decision.? Anytime you are implementing a feature that behaves differently (no matter how slightly) from the expected behavior in the given domain, you should always present your reasoning to the client and work with them to either fix the underlying problem or bring the feature in line with the expectations of the users.

On the other hand, “implementation details” are rarely of interest to clients (there are some exceptions, but in my experience they are the proverbial proof to the rule).? I am well known in some circles for my habit of waving my hand and dismissing a discussion as “implementation details” whenever a member of the team would attempt to engage the client in a discussion of underlying technology.? If the client has the knowledge and ability to make the hard technical decisions that your team cannot, why would they want to hire your team in the first place?? Instead, they are trusting you to provide them with the appropriate technological foundation to solve their target problem.

The other reason I distrust developers who want to involve the client in a low-level technical discussion is that inevitably they seem to want to use the existing state of the system as proof that feature A can't be done and should be scrapped.

Ed: Well, Steve, you see, we can't really do an unlimited undo/redo because we are actually running in separate processes, and in order to do it properly we'd have to correctly synchronize all the inter-process data calls and make sure that the interfaces are all correctly locked and thread-safe.? Unfortunately that will pretty negatively impact your performance.? On the other hand, we could just implement a message-passing system that will handle all the synchronization for us, but then we'd need to guarantee that the messages are all processed in order, and we'd still need to address the issue of whether or not we could undo the messages and still maintain the correct internal state across both processes.? Of course, we could always just combine all our processes and do away with the whole synchronization issue, but then you wouldn't bee able to scale up if the computing needs outgrow the abilities of a single machine.? So what do you think Steve?? Should we implement a thread-safe API, a message passing system, or return to a single-process implementation?

Steve:? Ummm, well that sounds hard, so maybe we should leave everything as it is…

Ed:? Good choice Steve.? Good choice…

These types of discussions are just another way to confuse the client into doing what you want, as opposed to getting at what the client wants.? Inevitably the more the client is involved in these types of discussions, the less likely the end result will be what the client needs or wants.

Please notice that I am not advocating keeping the customer in the dark.? By all means, provide them with technical information about the way the system works.? But always phrase the discussion in terms of the abilities and benefits that the different technologies and approaches provide to the users.? The client probably doesn't care whether you implement a polling system to pull data from the server or a push system to send data to the clients, but they do care about the differences in user experiences that result from those differences.? Stick to those discussions and provide the underlying implementation details only as necessary to illustrate your points.? In the end, you will find that the client will be much happier with the outcome, regardless of the particular decisions that may get made under the hood.

Posted in Customer, Development | Comments Off