I celebrated the start of 2012 staying with friends in the countryside. As I made coffee on new year's morning, I saw a tea-towel hanging above the stove. On it was written a testament to farmers, and I think it provides a compelling argument for growth and balanced budgets - the perfect prescription for what will for many be an austere year...
Let the wealthy and great
Roll in splendour and state.
I envy them not, I declare it.
I eat my own lamb,
My own chickens and ham.
I shear my own fleece and I wear it.
I have lawns, I have bowers,
I have fruits, I have flowers,
The lark is my morning alarmer.
So jolly boys now
Here's God speed the plough
Long life and success to the farmer.
I wish you long life and success for 2012!
Showing posts with label growth. Show all posts
Showing posts with label growth. Show all posts
Wednesday, 4 January 2012
Monday, 26 July 2010
10,000 to one - how smart design boosts customer support performance
When you're managing (or planning) a high-growth online service, one of the key considerations is customer support. While you can increase the capacity of your servers and boost the bandwidth to meet demand, your reputation could fall apart if you're not able to support growing numbers of visitors.
While banks and retailers often plan on a visitor to customer support ratio of 500:1 and a typical ISP may achieve 1500:1, many online services aim much higher. Here are two essential features of customer support:
But with careful management it is possible to give your visitors accessible customer support without impairing growth. The key is to provide the support, but minimise the chances that each visitor will want to use it!
This is a risky process - get it wrong and your customer support team will be under pressure - but the secret is to use poka-yoke design principles to ensure that visitors don't need any additional help.
Poka-yoke (roughly translated as "mistake avoidance" or "idiot-proofing") involves designing processes that reduce the chances of problems arising during a process - in this case the experience a visitor has of the service they are visiting. Here are some design considerations that can help reduce the chances that visitors will need human customer support:
To serve the needs of 10,000 visitors with a single customer support team member, each visitor can occupy only 2.9 seconds of an 8 hour working day assuming that their support requests are evenly spread! Since they never are evenly spread, and since the typical support request takes longer than 2.9 seconds to deal with, it's worth applying a queueing model to assist with analysis and preparation.
So, even assuming even distribution, if your customer support requests typically take 5 minutes (300 seconds) to deal with, you need to ensure that fewer than 1% of your visitors need help.
When we first launched Bmycharity we had a tiny fraction of the visitors that the service now enjoys, but we were very cautious about offering any real-time phone or online support, relying on webforms and email instead. But over the years we systematically redesigned the site. We made real-time phone support prominently available, and we addressed the design of every process element that feedback indicated caused visitors trouble. We never perfected the process, but we were able to sustain dramatic growth in visitor numbers without increasing our customer support resources - and we regularly received recommendations for our prompt response to support requests.
While banks and retailers often plan on a visitor to customer support ratio of 500:1 and a typical ISP may achieve 1500:1, many online services aim much higher. Here are two essential features of customer support:
- it can help delight customers and win loyalty - especially among those who initially have a problem
- but it contributes the highest share of variable cost to many online businesses
But with careful management it is possible to give your visitors accessible customer support without impairing growth. The key is to provide the support, but minimise the chances that each visitor will want to use it!
This is a risky process - get it wrong and your customer support team will be under pressure - but the secret is to use poka-yoke design principles to ensure that visitors don't need any additional help.
Poka-yoke (roughly translated as "mistake avoidance" or "idiot-proofing") involves designing processes that reduce the chances of problems arising during a process - in this case the experience a visitor has of the service they are visiting. Here are some design considerations that can help reduce the chances that visitors will need human customer support:
- keep site layouts simple
- minimise the number of options and decisions in the process
- use logical steps to break down the process into intuitive components
- use automated verification and form checking wherever possible and give real-time feedback
To serve the needs of 10,000 visitors with a single customer support team member, each visitor can occupy only 2.9 seconds of an 8 hour working day assuming that their support requests are evenly spread! Since they never are evenly spread, and since the typical support request takes longer than 2.9 seconds to deal with, it's worth applying a queueing model to assist with analysis and preparation.
So, even assuming even distribution, if your customer support requests typically take 5 minutes (300 seconds) to deal with, you need to ensure that fewer than 1% of your visitors need help.
When we first launched Bmycharity we had a tiny fraction of the visitors that the service now enjoys, but we were very cautious about offering any real-time phone or online support, relying on webforms and email instead. But over the years we systematically redesigned the site. We made real-time phone support prominently available, and we addressed the design of every process element that feedback indicated caused visitors trouble. We never perfected the process, but we were able to sustain dramatic growth in visitor numbers without increasing our customer support resources - and we regularly received recommendations for our prompt response to support requests.
Subscribe to:
Posts (Atom)