Interview questions that reveal whether customers actually want peer support

The questions below investigate recent behaviour before introducing a community concept. They are suitable starting points for English customer research, not a fixed script.

What to take away

Each question exposes a distinct design issue, so select the prompts that address the decision you actually face.
Follow the participant's account across documentation, search, colleagues, support and unofficial groups without suggesting options they did not mention.
Recruit people who did not join or stopped participating, and compare tasks, workarounds, limits and contradictions across sessions.

1. What were you trying to achieve the last time you needed help?

Establish the task in the participant's words. Ask when it happened and what made the outcome important.

2. Where did you look first?

Follow the actual sequence across documentation, search, colleagues, support and unofficial groups. Avoid suggesting options the person did not mention.

3. What made that route easy or difficult?

Look for access, trust, time, language and confidence issues. A complaint about a channel may conceal a problem with the answer itself.

4. When would advice from another customer be useful?

Ask for a concrete case. Then explore when peer advice would be unsafe, too sensitive or insufficiently authoritative.

5. What would stop you asking in front of other members?

Possible barriers include professional reputation, account details and fear of an unhelpful response. Do not offer these examples until after the participant answers.

6. Have you helped somebody else with a similar problem?

This reveals the supply side of participation. Ask what effort was involved and why the person chose to help.

7. How would you decide whether an answer was trustworthy?

Explore evidence, identity, moderation and expert confirmation. Do not assume that a staff badge or popularity count settles the question.

8. Which conversations should remain private?

Clarify whether privacy means private from the public, other members, the organisation or a future employer. The answer affects permissions and research handling.

9. What would make you return after receiving an answer?

Distinguish a one-off support visit from an ongoing relationship. Some useful services do not need habitual participation.

10. What happened when you used an existing group?

Ask about a recent example, including why the group was chosen and whether the outcome helped. Do not ask participants to rate unnamed alternatives from memory.

11. How should poor behaviour be handled?

Use a realistic scenario if the topic is too abstract. Record expectations about warnings, removals, appeals and staff involvement without promising a policy during research.

12. What should the organisation do next?

Invite advice at the end, after present behaviour is clear. Treat the suggestion as one input, not a requirement to build the requested feature.

Run and interpret sessions responsibly

The GOV.UK Service Manual advises research teams to plan sessions around what they need to learn and to obtain informed consent. It covers UK public-service research; a business must adapt its process and privacy information to the project.

Run Sessions Responsibly

Plan sessions around what you need to learn
Obtain informed consent before starting
Use follow-up prompts, not praise
Mark policy explanations separately
Never ask for passwords or secrets
Keep notes separate from interpretation

Use follow-up prompts such as "what happened next?" and "can you show me?" rather than praising an answer. Silence can give a participant time to remember. If the interviewer must explain the organisation's policy, mark that part of the conversation so it is not later coded as an unaided customer view.

Do not ask for passwords, account secrets or another person's identifiable information. When a participant begins sharing unnecessary detail, interrupt gently and redirect. Agree beforehand how the note taker will flag material that should not remain in the research record.

Recruit across relevant experience, including people who did not join or stopped participating. Keep interviewer notes separate from interpretation. After several sessions, compare tasks, workarounds, limits and contradictions rather than counting the number of times an attractive phrase appears.

Set the number of sessions from the segments the decision affects. Research on saturation often cites around twelve interviews for a relatively homogeneous group. For a community decision, split that total across current members, people who did not join, people who stopped participating, and staff who handle support.

If the segments differ in task or access, plan separate sessions for each. Stop when new sessions add no new tasks, workarounds or limits.

The interview output should change a choice: the initial audience, activity, access model, moderation boundary or decision not to proceed. If it merely produces a page of favourable quotations, the research question was too weak or the analysis too selective.

Consider the difference between a favourable quotation and a coded finding. A favourable quotation praises the community as friendly. That line does not identify a task, a barrier or a choice.

A coded finding records that people who did not join could not tell whether they could read posts before buying. That finding points to a change in the access model or in how the community is described in public.

Before you act

Select prompts that address your specific decision.
Obtain informed consent before starting research.
Recruit people who did not join or stopped participating.
Decide how the output will change a choice.

Common questions

How should I use the twelve questions in a session?

The list was not ranked, and asking all twelve does not guarantee a representative finding.