In planning a new website for a client, I'll get the chance to
observe their call centers and sales process in addition to
interviewing the company's representatives.
I am developing lists of questions to use when interviewing these
teams, and I thought I'd ask for your input.
I can't get too specific about the client, so at a high level, what
topics would you try to cover when interviewing the following teams?
1) Inbound sales call center
2) Customer support call center
3) Face-to-face sales representatives
4) Sales manager
5) Customer support manager
I've worked with call centers for a long time. You've probably
thought of at least some of these, and some seem simplistic and
obvious, but here are questions I find helpful.
For groups 1, 2, and 3
- Why do people call/email/chat with/come see you?
- What are they usually trying to do?
- What steps work and which seem problematic?
- What frustrates them?
- What frustrates you (the agent)?
- How else can people do what they ask you to do for them?
- How would they know about that?
- Why don't they use other methods?
- Where are they when they contact you?
- Do you use scripts? If so, are they in line with other channels
(web, IVR, collateral, etc.)?
- How do you keep and access knowledge?
For 4 and 5, I would ask similar questions, though with a management
focus. And ask them separately from the other groups to avoid even
subtle influence. Doing so will usually raise some interesting
conflicts that can be further explored.
That's not everything, but I hope it helps!
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
I suggest asking if there is any seasonality to calls. Depending on
your client, they may have more products sold at a certain time of
year, need certain functionality/reporting help at tax time or end of
year, or get more calls when a quarterly upgrade occurs.
I also ask for reports or metrics - these are often broken out for
various tiers in support levels (Tier 1- simple answers; Tier 3
complex, technical follow-up).
I ask manager how their team is measured for success or performance?
This could impact their approach to their work.
What work arounds they have developed or learned form a co-worker.
What work seems redundant or should be simpler?
One presenter at UPA mentioned asking about what others have a
problem with so you deflect the discomfort the intervieweee may have
with telling a less flattering story.
I always ask for copies of cheat sheets or locally saved
documentation that is better handled as version controlled/open
documentation and I watch for sticky notes.
For any type of field study (including, even especially, call centres), I've
found this book invaluable:
Hackos and Redish: User and task analysis for interface design (Wiley)
Despite the name, this is actually a book about going to observe users in
their natural habitat and finding out what they do. It's still the best book
on the topic even though it was published in 1998. The best bit about it
having been out for ages is that you can pick up a good second-hand copy for
about $15 including shipping.
As with any book written by Ginny Redish, it's amazingly clear and
And one quick tip: I ask people to save up examples of three types of work
ahead of my visit:
- something easy
- something typical
- something difficult, important, or that they'd be upset if it went wrong.
They're usually quite willing to do that because it doesn't sound onerous
(and it isn't). This then opens the door to a conversation about what
'easy', 'typical' and 'difficult' might mean to them. I've found that if I
_don't_ do this, then they tend to focus only on the difficult/important
stuff - which is well worth finding out about, don't get me wrong, but which
then obscures the everyday humdrum stuff which is actually the bulk of the
Personally, I would start with a question for yourself: what is it
that you want to find out about? That should guide the questions that
you ask of the staff.
If you're not clear what it is that you want to find out, then your
research could be aimless.
Of course, feel free to change mid-stream if some interesting stuff
comes up that you didn't anticipate, but having a framework to guide
things is useful so that you don't get distracted into irrelevant
topics and focus instead upon what is relevant to what you want to
I'm at the footstep to a similar problem, I'm so glad you asked
Phillip, that's an excellent start! Much appreciated. Thanks
jason at jasonrobb.com
You might want to check out Steve Mulder's book on Practical Personas
although I'm not recommending you build personas as a response to
One of the things I got from his book was about the script being
there primarily to keep the conversation going; the real goal is
getting the person on the other end talking about what's important
to them; be open to dialogue that is off-topic and not on the script.
That said, is your goal to uncover end user needs or to collect
stakeholder needs..or both? Because each of these roles has different
connections to the customer and different perspectives. They will
probably be most responsive to you when your questions seem to
For example, if you are improving on a feature in the product that is
currently below "par" in the competitive landscape, the sales people
will probably be happier since they won't have to defend the current
product deficiency in their meetings.
If you are talking to the phone support staff about high frequency
call topics and mention how you are trying to reduce the volume of
these through design changes, they may love you for that. Or, maybe
you are putting a heavy paper-process into online format such as a
registration one-off that currently isn't available on the website.
In short, I think it would be helpful to know what your goals are:
customer input or stakeholders...or are the customers internal?
It's hard to suggest questions not knowing what you want to get out
p.s. listening to inbound calls an hour a week in the call center is
a great way to learn about the customers and call center staff at the
I agree call listening is a great way to do user research. You'll
likely find interesting and revealing gaps between what you learn
from your interviews and from what you observe in call center
interactions. You might also ask for call recordings, if they're
available, so that you can more accurately capture what's really
Sr. Voice User Interface Designer
One thing to consider would be the questions that different
stakeholders on the product team have. You could invite stakeholders
from product management, QA, training, doc, development, etc. to each
list all the questions that they might have and then review those.
This method of asking each group what questions can also lead to
insights about different perspectives of the groups and even biases
that they might have. I've done this using the brainwriting technique
where you go to a meeting of a group of stakeholders, give each person
a page, and then ask them to quite a few questions that might might
want to ask users. After a minute or 2, you have them hand their
questions to the person next to them who then adds his/her questions,
then you do that one or two more times and you have a large list of
questions in 5-10 minutes. You can look for themes that cut across
groups and key concerns.
On Tue, Jun 30, 2009 at 10:12 AM, Alan Salmoni<alan at usernumber1.com> wrote:
> Personally, I would start with a question for yourself: what is it
> that you want to find out about? That should guide the questions that
> you ask of the staff.
> If you're not clear what it is that you want to find out, then your
> research could be aimless.
> Of course, feel free to change mid-stream if some interesting stuff
> comes up that you didn't anticipate, but having a framework to guide
> things is useful so that you don't get distracted into irrelevant
> topics and focus instead upon what is relevant to what you want to
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help