Software Engineering - Measuring Customer Satisfaction

Author

Measuring Customer Satisfaction

United

2006-05-22, 8:03 am

Hi all,

My company, a small software house, that is thinking about starting to
measure customer satisfaction.
This will involve looking at the product itself, and the customer support
team, that support the package

Does anybody have any examples of customer satisfaction surveys that could
be used for such a purpose ?

Any key points that I should be measuring would be very much appreciated
Thanks for your help

Con.

Suyash Agnihotri

2006-05-23, 8:03 am

1- First you need to decide on the aspects where want customer
feedback.
For example you can choose Requirement elicitation capabilities,
Technical capabilities and Project Management capabilities.
2- Then you need to frame questions for each of these aspects.
For example: Were we able to capture all your requirement?
3- ask customers to give rating for each question you asked.(may be 1
to 5, 5 being best)

Analyze the same and you got what you were looking for.

If your project is big (more than 6 months) then i would suggest you to
do this in regular intervals, so that you can use this data for that
perticular client. However for smaller projects you can do this
exercise at the time of project closure.

-Suyash

H. S. Lahman

2006-05-23, 7:04 pm

Responding to United...

> My company, a small software house, that is thinking about starting to
> measure customer satisfaction.
> This will involve looking at the product itself, and the customer support
> team, that support the package
>
> Does anybody have any examples of customer satisfaction surveys that could
> be used for such a purpose ?

Not really. The problem is that customer satisfaction is very difficult
to quantify. Ultimately it depends upon the specific product (e.g., How
do you value the XYZ feature of Model ABC from 1 to 5). Clearly
customer satisfaction will vary from product to product and even from
feature to feature within a product.

> Any key points that I should be measuring would be very much appreciated

The first thing you have to figure out is what level of satisfaction you
care about. The Marketeers generally try to evaluate at one to these
levels:

Corporate: How does the customer feel about the overall company?

Product Line: How does the customer feel about a particular line of
products?

Product: How does the customer feel about a particular product?

Model/Release: How does the customer feel about a particular model of
the product (or release of the software)?

Feature: How does the customer feels about a specific product feature?

Obviously your questions need to get much more specific as you move down
this list.

The next thing you need to think about is how you would map customer
satisfaction back into what you do. This is especially important if you
are interested in improving customer satisfaction; you need to be able
to identify root causes of satisfaction that map into the way you do
things. The most common categories are:

Reliability: How often does the product break in some fashion?

Feature set: Did the customer get the expected features and were they
the right ones?

Schedule: Did the customer get the product at the promised time?

Ease of use: Did the customer find the product easy to use? This
includes evaluating things like documentation and customer training.

Performance: Does the customer feel the company has been helpful,
responsive to problems, knowledgeable, and other aspects of post-sales
customer support.

Utility: Does the customer use the product extensively? [One common
measure is repeat sales. I recall a capital equipment vendor who had
4-5 primary customers who bought several systems at a time and were
regular repeat buyers. But the company also had dozens of sales of 1
system with no repeat buys. The problem lay in the infrastructure the
customer needed to use the product effectively. Only a few companies
had the necessary commitment to the infrastructure to make the product
useful, even when it was reliable, had the expected features, and was
delivered on time. The product was easy to use for experts, but without
infrastructure there were no in-house "experts".]

It is often useful to break out feature sets as classic marketing groups:

Necessary: Essentially checklist features that the product must have or
it is not competitive. If missing the customer will be dissatisfied.

Preferred: Features that the customer would like to have but does not
require. Such features provide a competitive advantage. If absent the
customer will probably be only marginally satisfied.

Excitement: Features the customer did not expect but likes. These
features lead to "blockbuster" products". If present the customer will
be very satisfied.

Any questions that you ask should have a pretty clear link to one of the
categories that you choose to focus upon. Thus asking whether the
customer likes the color of the system hardware doesn't have anything to
do with software but it it might have a lot to do with whether the
customer is satisfied with the overall product feature set.

Finally, you have to look at what your goals are in trying to determine
customer satisfaction. Is there a specific problem (e.g., lack of
repeat sales, complaints about too many bugs, etc.) that is the real
reason for the sudden interest n customer satisfaction? If so, any
survey needs to be tailored to that goal.

As far as quantification is concerned, the traditional Delphi approach
is pretty much it. That's because satisfaction is inherently subjective
so usually only relative valuations are useful. You ask a series of
questions of the form: Rate how strongly you are satisfied with X from 1
to N. It is the way you categorize the questions that identifies
problems on a comparative basis. That is, the answer to any one
question is probably not very useful but when the answer to one question
averages much higher or lower than other questions, you know there is
something special about that question's category.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Sponsored Links