Turning user-conference feedback into product and service actions
The survey has closed, hundreds of comments have arrived, and product, support and the events team each want something different from them.
The short answer
User-conference feedback is only useful if it reaches someone who can act on it. Sort it by type, route each type to a named owner, decide what becomes an action and tell the people who gave it what happened.
Plan this before the survey is written, because the questions decide what you can route. The event owner coordinates the process. Product and service decisions stay with the teams that own them.
Decide the routes before collecting feedback
| Feedback type | Example | Owner | Typical action |
|---|---|---|---|
| Product request | Wants a reporting feature | Product lead | Log in the product backlog and reply on status |
| Product defect or support | Describes a recurring fault | Support or customer success | Check against open cases and contact the customer |
| Service or account | Slow response, unclear contact | Customer success lead | Account owner follows up |
| Content and programme | Wants more hands-on time | Event owner | Feeds next programme design |
| Venue and logistics | Sound, seating, food, signs | Event owner or project lead | Added to supplier and venue review |
| Conduct or safety | Describes a serious incident | Named conduct contact | Handled outside the survey process |
Collect in a way that can be routed
- Keep product, service and event questions in separate sections so answers do not blend.
- Ask each respondent whether they are a buyer or a practitioner, so views can be compared (see separate journeys).
- Offer an optional follow-up consent question, so customers who expect a reply are not left guessing.
- Decide whether responses are anonymous, confidential or attributed, and say so on the form. See anonymous feedback boundaries.
- Use consistent scales across sessions so results can be compared. The survey scale guide covers this.
Turn comments into actions
- Group open comments into themes. The open-text feedback coding guide shows a method.
- For each theme, note how many respondents raised it, and in which group.
- Give each theme to the owner in the routing table with a date by which they will say what they will do.
- Prioritise using criteria the owners agreed beforehand, such as number of customers affected, severity and effort (see feedback action prioritisation).
- Record each decision, including a decision not to act, with a short reason.
Do not promise more than the owners can deliver
A conference is an emotional point in a customer relationship. A reply that says a feature will be built can be quoted back for years.
Agree the language before replies go out: heard, logged, under review, planned, not planned. Let the product owner approve any statement about the roadmap.
Close the loop with customers
- Send a summary to all attendees soon after the event, covering what you heard and what is being done.
- Contact customers who raised a serious issue individually and record the contact.
- Show next year's programme changes that came from feedback, so people see their answers matter.
- Report to leadership separately for buyers and practitioners, as the findings often differ.
Worked example · Fictional example
A fictional inventory-software user conference
Fictional organisation and figures, for illustration only.
Stok Mudah, a fictional inventory-software company, receives 190 survey responses from a 400-delegate conference. Comments mix product requests, support frustration and complaints about the lunch queue.
The event owner tags each comment with a type and owner, and finds that practitioners mention a reporting gap in about a third of responses while buyers mention response times. Product agrees to review the reporting request and reply with a status within an agreed date, support follows up on named cases, and the lunch issue goes to the venue review. The summary email to attendees says what is under review and does not promise dates.
Use this yourself
Feedback action register
Copy this table and add one row per theme. Review it with the owners at a set date after the conference.
| Theme | Type | Raised by (count, group) | Owner | Decision and reason | Reply wording and date | Status |
|---|---|---|---|---|---|---|
| Short description | Product, service, programme, venue or conduct | Number and buyer or practitioner | Name | Act, review, defer or not act, with reason | Heard, logged, under review, planned or not planned | Open or closed |
Handle it in-house, or bring in help?
Your team can usually handle this when
- The audience is small enough to read every comment.
- Product and customer success already have a routine for acting on feedback.
- One person can coordinate the register and replies.
Outside planning help earns its fee when
- Feedback must be split among product, support, events and leadership with different timelines.
- Buyers and practitioners disagree and the report must show both without blending them.
- Replies to customers need coordinating across teams so wording is consistent.
Need the feedback turned into an owned action list?
A conference project lead can set the routing table before the survey, code comments into themes with your teams, run the action register and prepare the reply wording for owners to approve. Product and service decisions remain with your teams.
Questions organisers ask
How soon should customers hear back?
Agree a date internally before the survey opens and tell respondents. A short summary soon after the event, with individual replies later, is common.
Should feedback be anonymous?
It depends on whether you want to reply. Decide, state it on the form and follow it. Anonymous responses cannot be followed up individually.
What if buyers and practitioners disagree?
Report them separately. The disagreement is often the most useful finding.
Who decides what the product team builds?
The product team does. The event team supplies organised evidence and keeps the register current.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.