Customer Feedback Glossary: 63 Terms, Metrics & Methods

Customer feedback vocabulary can feel unnecessarily complicated. This glossary explains the most useful terms in plain language, with examples for product, UX, marketing, and customer-success teams.

Quick answer: what is customer feedback?

Customer feedback is information people share about their experience with a product, service, website, or brand. It can be qualitative, such as a written comment or interview, or quantitative, such as a rating, survey score, or response-rate metric.

The most useful feedback is specific, collected close to the relevant experience, and connected to an action. A short in-app survey after a user completes a workflow, for example, can reveal more than a generic question sent weeks later.

Customer feedback and UX terms

Customer feedback

Customer feedback is any opinion, observation, request, complaint, or rating shared by a current or prospective customer. Feedback can describe what happened, how the person felt, what they expected, or what they want to change.

Customer feedback is broader than a survey response. It also includes support conversations, reviews, interviews, usability-test observations, feature requests, and feedback collected through a website widget. A useful feedback record preserves the original words, the experience being discussed, and enough context to decide what to do next.

For example, “checkout is confusing” is a signal, while “three new users could not find the tax total on mobile checkout” is more actionable because it identifies the audience, workflow, and possible product problem. When collecting feedback, ask what decision the response will inform before choosing the question or channel.

User feedback

User feedback is input from someone who uses a product or service. The terms user feedback and customer feedback are often used interchangeably, but they can describe different audiences: a user might not be the buyer, administrator, or contract owner.

For B2B products, separating feedback from end users, champions, administrators, and economic buyers helps teams understand whose problem they are solving. A user may report that a workflow is difficult even when the buyer is satisfied with the contract or renewal process. Store the respondent’s role and usage context when that distinction affects prioritization.

Product feedback

Product feedback is input about a product’s usefulness, functionality, usability, reliability, or direction. It can include praise, problems, feature requests, questions, and reactions to a new release.

Product feedback is not the same as a product roadmap. A request such as “add a bulk export button” is evidence of a need, but the underlying job may be “move a complete dataset into another system.” Ask what the customer is trying to accomplish before treating the requested solution as the requirement.

Customer complaint

A customer complaint is an expression of dissatisfaction about a product, service, interaction, or outcome. Complaints often contain both an emotional reaction and a concrete failure, such as an unexpected charge, a missed deadline, or a broken workflow.

Route urgent complaints quickly, but do not assume that the loudest complaint is the most important product problem. Tag the issue, affected journey stage, severity, and resolution status so individual cases can be compared with recurring themes.

Voice of the Customer (VoC)

Voice of the Customer is the structured practice of collecting, analyzing, and sharing what customers need, expect, and experience. VoC programs combine several sources, such as surveys, reviews, interviews, support tickets, and product feedback.

The goal of VoC is not simply to collect more comments. It is to identify recurring needs and make them visible in product, design, marketing, and customer-success decisions.

A practical VoC program defines which customer groups matter, which touchpoints are monitored, who reviews the evidence, and how findings become decisions. A quarterly NPS survey without ownership, segmentation, or follow-up is a measurement exercise—not a complete VoC program.

User experience (UX)

User experience, or UX, is the overall experience a person has while interacting with a product, service, or website. It includes usability, accessibility, usefulness, clarity, trust, and the emotions created by the interaction.

UX is not the same as visual design. A polished interface can still create a poor UX if users cannot find information, complete a task, or recover from an error.

When collecting UX feedback, ask about a specific task rather than the interface in general. “Could you find the export option?” followed by “What, if anything, made that difficult?” gives the team more useful evidence than “Do you like the design?”

Customer experience (CX)

Customer experience is the broader relationship someone has with a company across all touchpoints, including marketing, sales, onboarding, product use, support, billing, and renewal. UX is often one part of the overall CX.

Use the distinction when diagnosing a problem. A confusing settings page is primarily a UX issue; a customer who was promised an integration during sales but cannot access it has a broader CX issue. Both can produce negative feedback, but they may have different owners and remedies.

Customer journey

A customer journey is the sequence of stages and interactions a person moves through while becoming aware of, evaluating, buying, using, and continuing with a product or service. Common stages include discovery, evaluation, onboarding, adoption, support, renewal, and advocacy.

Map feedback to the journey stage where the experience occurred. A customer may give a high overall satisfaction score while still reporting a serious onboarding problem that prevents long-term adoption.

Touchpoint

A touchpoint is any interaction between a customer and a company, product, or service. Examples include an ad, pricing page, sales call, signup form, onboarding email, in-app workflow, support reply, invoice, or cancellation screen.

Touchpoints make feedback more specific. Instead of asking “How do you feel about our company?”, ask “How easy was it to find the information you needed on the pricing page?” and record the page or journey stage as metadata.

Customer insight

A customer insight is an evidence-backed conclusion about a customer’s need, motivation, behavior, or experience that suggests a decision or action. It is more than a comment or a metric: it explains what the evidence means and why it matters.

For example, “12 users requested templates” is feedback data. “New users struggle to start because they do not know what a successful first project looks like” is an insight that could lead to templates, examples, or better onboarding. State the evidence, affected segment, and recommended next step when sharing an insight.

Friction

Friction is anything that makes a task slower, harder, less clear, or less pleasant than it should be. Examples include confusing copy, too many steps, slow loading, missing information, and unexpected errors.

Feedback helps teams find friction that analytics alone may show but cannot explain. A drop-off in a form tells you where users leave; a short feedback question can help explain why.

Measure friction at the moment it occurs. For example, after a failed import, ask “What stopped you from completing the import?” and attach the file type, error code, and step reached as metadata. This combines the customer’s explanation with the behavioral context needed to reproduce the problem.

Pain point

A pain point is a recurring problem that causes difficulty, frustration, cost, risk, or lost time for a customer. A pain point is more useful than an isolated complaint when it appears across a meaningful group of users or has a material effect on an important workflow.

Separate the symptom from the pain point. “I need a CSV export” may be the requested solution; “I cannot move my reporting data into our finance system” is the underlying pain point. Ask about frequency, impact, and the workaround before prioritizing it.

Feedback widget

A feedback widget is a small interface element that lets people submit feedback from a website or application. It can be a floating button, popup, embedded form, reaction control, rating prompt, or short survey.

Feedback widgets reduce the distance between an experience and the question about that experience. tinyDialog widgets can be embedded in websites and Notion pages, opened from a custom button, or triggered from application code.

Place the widget where its question is answerable. A “Was this documentation helpful?” prompt belongs near the end of the page; a “What stopped you from signing up?” prompt belongs after an abandoned or failed signup event. Give people an obvious way to dismiss it, and avoid covering navigation or the primary action.

In-app feedback

In-app feedback is feedback collected inside a web or mobile application while a user is using it. Common formats include a quick rating, an open comment, a feature request, a bug report, or a survey shown after a specific event.

In-app feedback is usually more contextual than an email survey because the user can respond while the experience is still fresh.

Use event-based targeting to make the prompt relevant: after a completed setup, following an error, or when a user has used a feature several times. Do not show a generic “Any feedback?” prompt to every visitor if you need to understand a specific workflow.

Contextual feedback

Contextual feedback is input collected at a relevant moment, location, or user journey stage. Examples include asking how helpful a documentation page was, requesting feedback after onboarding, or asking why a user abandoned a workflow.

Context improves interpretation. A response to “How was this?” is easier to act on when you know which page, feature, or task the person just experienced.

Context does not mean collecting everything about a person. Capture only what helps interpret the response—such as page, feature, journey stage, plan, or event—and explain the purpose of that data where appropriate.

Solicited feedback

Solicited feedback is input a team deliberately requests through a survey, interview, feedback prompt, usability test, or research study. Because the team controls the question and audience, solicited feedback is useful for investigating a known decision or experience.

The trade-off is that the question can shape the answer. If you want to learn why users abandon onboarding, ask an open neutral question at the relevant step instead of asking only people who completed onboarding to rate it.

Unsolicited feedback

Unsolicited feedback is input a person shares without being invited to answer a specific question. Reviews, support tickets, community posts, social comments, and emails are common examples.

Unsolicited feedback often reveals issues a team did not think to ask about, but it is not automatically representative. Treat it as a discovery signal, then validate the pattern with a targeted survey, interview, product data, or a broader sample.

Passive feedback

Passive feedback is feedback a team receives without actively asking a person a question. Examples include support tickets, app-store reviews, social posts, community discussions, and unsolicited emails.

Passive feedback overlaps with unsolicited feedback, but the terms emphasize different things: unsolicited describes whether the person was asked, while passive describes how the team receives the signal without interrupting the experience. Passive feedback can reveal issues people care enough to report, but it may overrepresent unusually happy or unhappy experiences. It works best alongside active, consistently worded feedback.

User research terms

User research

User research is the systematic study of people’s needs, behaviors, motivations, and experiences to inform product or service decisions. Researchers use methods such as interviews, observation, surveys, usability testing, diary studies, and analysis of existing feedback.

User research helps a team understand not only what users do, but also what they are trying to accomplish and why.

Start research with a decision, not a method. “Should we build bulk export?” is a solution question; “How do customers move reporting data today, and where does that workflow break?” is a research question that can reveal whether export is the right answer.

Qualitative research

Qualitative research explores meaning, context, motivations, and the reasons behind behavior. It usually produces words, stories, observations, or recordings rather than primarily numerical data.

Customer interviews, usability tests, open-ended survey answers, and support conversations are common qualitative sources.

Use qualitative research when you need to discover language, motivations, or failure modes. For example, five interviews may reveal that users call the same workflow “publishing” even though the product calls it “deploying.” That insight can improve labels and the next survey’s wording. Qualitative findings explain patterns, but they should not be presented as percentages unless they were measured quantitatively.

Quantitative research

Quantitative research measures patterns in numerical data. It can answer questions such as how many users encountered an issue, which option people prefer, or whether satisfaction changed after an update.

Ratings, multiple-choice surveys, response rates, and product-usage metrics are common quantitative sources.

Qualitative and quantitative research answer different questions. Numbers can show the size of a problem; conversations and written feedback can explain the problem.

A practical sequence is to use qualitative research to discover possible problems, a survey or product data to estimate how common they are, and follow-up research to test the proposed solution. Do not use a high response count to compensate for a poorly defined audience or a biased question.

Customer interview

A customer interview is a structured conversation with a customer or user to learn about their goals, behavior, problems, and perceptions. Good interviews use open questions and follow-up prompts instead of trying to persuade the participant or validate a predetermined answer.

Interviews provide depth, but they are time-consuming and usually involve smaller samples than surveys.

Ask about recent behavior before asking for opinions. “Tell me about the last time you had to export a report” usually produces better evidence than “Would you use an export feature?” Follow up on the steps, workaround, frequency, and impact; stated interest in a hypothetical feature is weaker evidence than a repeated problem in a real workflow.

Focus group

A focus group is a moderated discussion with several participants about a product, concept, need, or experience. It is useful for hearing different perspectives, learning the language customers use, and exploring reactions to early ideas.

Focus groups are less reliable for measuring individual preference because participants can influence one another. Use them to generate hypotheses and questions, not as a substitute for observing people complete a task or independently measuring behavior.

Diary study

A diary study asks participants to record experiences, behaviors, or thoughts over multiple days or weeks. Entries may be written responses, voice notes, screenshots, or short check-ins prompted by an event.

Diary studies are useful when the experience is infrequent, changes over time, or happens in a real-world context that a one-hour interview cannot capture. Keep prompts specific—for example, “Record the next time you compare project-management tools and what caused you to switch”—and account for incomplete entries.

Usability testing

Usability testing is a research method in which people try to complete realistic tasks while a team observes where they succeed, hesitate, or fail. The purpose is to identify usability problems and opportunities for improvement.

Asking participants what they would do is not a substitute for observing what happens when they actually perform a task.

Give participants a realistic goal without revealing the interface path. For a billing flow, say “Upgrade your workspace and find the first invoice,” rather than “Click Billing, then Plans.” Record completion, hesitation, errors, and the participant’s explanation afterward. A short test with five well-recruited participants can expose severe usability problems, but it does not estimate the percentage of all users affected.

Participant

A participant is a person who takes part in a research study, survey, interview, or usability test. Researchers should define who is eligible, explain what participation involves, and avoid treating a convenient group as representative of every user.

Recruit against the decision you need to make. If onboarding is the problem, include new users who completed onboarding, abandoned it, and used a workaround—not only experienced customers who already understand the product.

Research repository

A research repository is an organized place for storing research notes, recordings, survey responses, findings, and related evidence. It makes insights easier to find and reduces duplicate research.

For lightweight feedback programs, a dashboard or connected tool such as Airtable can act as a practical repository when responses are tagged and reviewed consistently.

A useful repository preserves the source evidence alongside the synthesis. Store the research question, participant or segment, date, method, original quote or observation, theme, confidence, and linked decision. This makes it possible to check whether a roadmap conclusion is supported by evidence rather than by a memorable anecdote.

Survey and question-design terms

Survey

A survey is a structured set of questions used to collect information from a group of people. Surveys can be short or extensive, quantitative or qualitative, and delivered by email, on a website, in an app, or through a feedback widget.

The best survey is not the longest one. It is the shortest set of questions that can answer a clearly defined decision or research question.

Write a brief before writing the questions: define the audience, decision, timing, success measure, and how responses will be acted on. For example, if the decision is whether onboarding needs a redesign, ask recently activated users about the step that slowed them down instead of sending a general satisfaction survey to the entire customer base.

Feedback form

A feedback form is a structured interface for collecting written comments, ratings, requests, questions, or issue reports. It may be a standalone page, embedded form, contact form, or in-product widget.

Use a form when people need to initiate feedback or provide several details. Keep the required fields minimal, label the purpose clearly, and ask for context that helps the team respond—such as the affected page, expected outcome, actual outcome, and optional contact details. A form with too many required fields turns a useful report into an abandoned one.

Micro-survey

A micro-survey is a very short survey, usually one to a few questions, designed to capture feedback with minimal interruption. A star rating followed by an optional comment is a common micro-survey format.

Micro-surveys are useful for collecting feedback at scale, especially when they are triggered after a relevant action instead of shown at random.

Use one primary question per micro-survey. For example, after a user completes an import, ask “How easy was it to import your data?” and show an optional “What made it difficult?” follow-up. Do not combine unrelated questions just because the prompt is already open.

Open-ended question

An open-ended question lets people answer in their own words. “What made this task difficult?” is open-ended; it does not restrict the respondent to predefined choices.

Open-ended questions produce richer qualitative insight, but they take more effort to answer and require more analysis than a simple rating.

Closed-ended question

A closed-ended question offers a fixed set of answers, such as yes/no, multiple choice, a rating scale, or a set of checkboxes. Closed-ended questions are easier to compare and analyze.

Use an “Other” option or an optional comment when the available answers may not cover every valid response.

Use closed-ended questions when you need to compare segments or track a trend. Before launching, check that the choices are mutually exclusive where appropriate, cover the likely answers, and use a clear time frame such as “in the last 30 days.”

Leading question

A leading question nudges people toward a particular answer. “How much did you love the new dashboard?” is leading because it assumes the dashboard was loved.

Neutral wording produces more trustworthy feedback. “How would you rate the new dashboard?” leaves room for positive, neutral, and negative responses.

Look for leading assumptions in the premise, answer choices, and follow-up. “What did you like about the new dashboard?” excludes people who disliked it; “What was your experience with the new dashboard?” allows both positive and negative evidence.

Double-barreled question

A double-barreled question asks about two different things as if they were one. For example, “How satisfied are you with the product’s speed and reliability?” A user may like one and dislike the other, so the answer is difficult to interpret.

Split the question into two focused questions when both topics matter.

The same problem appears in statements used with agreement scales. “The app is fast and easy to use” produces one score for two judgments, so a team cannot tell whether speed or usability needs attention.

Likert scale

A Likert scale measures agreement, satisfaction, confidence, or another attitude across ordered response options. A common example runs from “Strongly disagree” to “Strongly agree.”

Keep the labels clear and consistent. Do not assume that a numeric scale means the same thing to every audience unless the endpoints are explained.

Use a Likert scale when you are measuring a statement or attitude, such as agreement with “I could complete my first project without help.” Keep the scale balanced with positive and negative options, include a neutral or not-applicable choice when justified, and avoid treating the resulting average as more precise than the response design allows.

Rating scale

A rating scale asks a person to evaluate something using ordered values, such as 1–5 stars, 0–10, or a set of emoji reactions. Rating scales make trends easy to summarize, but a score alone rarely explains what should change.

Pair a rating with an optional follow-up such as “What is the main reason for your score?” when you need actionable context.

Choose the scale that matches the construct. Stars work well for a quick visual satisfaction rating; a 0–10 likelihood question is associated with NPS; an easy-to-difficult scale is suitable for effort. Keep the wording and endpoints stable if you need to compare scores over time.

Screening question

A screening question determines whether someone is eligible for a survey or research study. It can identify a person’s role, product usage, plan, location, or recent experience.

Screening keeps responses relevant, but overly strict screening can exclude valuable perspectives.

Screen for experience, not for the answer you hope to receive. To study a failed checkout, include people who abandoned, completed with difficulty, and completed smoothly. Asking “Did you enjoy checkout?” as a screening question would remove the very users who could explain the problem.

Survey fatigue

Survey fatigue is the decline in attention, response quality, or willingness to participate caused by too many questions or too many survey requests. Short, focused surveys and sensible frequency limits help reduce fatigue.

Watch for straight-lining, rushed completion, skipped comments, and declining response rates as possible signs of fatigue. Coordinate surveys across teams so the same user is not asked for NPS, product feedback, and support feedback in the same week unless there is a clear reason.

Customer feedback metrics

Customer Satisfaction (CSAT)

Customer Satisfaction, or CSAT, measures how satisfied someone was with a specific interaction, product, or service. A common question is “How satisfied were you with your experience?” followed by a 1–5 scale or similar choices.

CSAT is most useful when tied to a clear event, such as a support interaction, onboarding step, or completed task. Teams should define how they calculate and segment the score before comparing results.

One common calculation is the percentage of respondents who choose a satisfied option, such as 4 or 5 on a 1–5 scale: satisfied responses ÷ total valid responses × 100. Report the question, scale, time period, segment, and response count with the score. A CSAT of 90% from 10 responses should not be treated as equivalent to 90% from 1,000 responses.

Net Promoter Score (NPS)

Net Promoter Score, or NPS, is a loyalty metric based on the question: “How likely are you to recommend this product or company to a friend or colleague?” Respondents answer on a 0–10 scale.

Scores of 9–10 are commonly called promoters, 7–8 passives, and 0–6 detractors. NPS is calculated as the percentage of promoters minus the percentage of detractors. It is a useful trend indicator, but it should not replace follow-up questions or other evidence.

Use NPS for a broad relationship or loyalty question, not as a diagnosis of a specific workflow. A detractor score tells you that something is wrong from the respondent’s perspective, but not whether the cause is pricing, reliability, support, or product usability. Ask for the main reason and analyze the comments by segment and journey stage.

Customer Effort Score (CES)

Customer Effort Score, or CES, measures how easy or difficult it was for someone to complete a task. A CES question might ask, “How easy was it to resolve your issue today?”

CES is especially relevant for support, onboarding, checkout, and other workflows where unnecessary effort can cause abandonment or repeat contact.

Ask CES immediately after the task being evaluated, and keep the task consistent between measurements. “How easy was it to resolve your issue today?” is more interpretable than “How easy is our product?” because the respondent can connect the answer to a recent experience.

Response rate

Response rate is the percentage of people who submit a response out of the people who were invited or shown a survey. The formula is:

response rate = completed responses ÷ eligible invitations × 100

Define the denominator carefully. A response rate based on widgets shown to eligible users is not directly comparable to one based on a broad email list.

For example, if 800 eligible users see a prompt and 120 submit a response, the response rate is 15%. State whether invitations were delivered, opened, or merely eligible to see the prompt; changing the denominator can make the same program appear to improve or decline.

Completion rate

Completion rate is the percentage of people who start a survey or form and finish it. A low completion rate can indicate that the survey is too long, the questions are unclear, or the experience is poorly timed.

Calculate completion rate as completed surveys ÷ started surveys × 100, and compare it with the drop-off point. If most users leave after an open-text question, shorten the required fields or make the comment optional rather than concluding that the entire survey topic is uninteresting.

Sample size

Sample size is the number of participants or responses included in a study or analysis. A larger sample can make quantitative estimates more stable, but sample size alone does not remove bias or guarantee useful feedback.

The right sample depends on the decision, audience, expected variation, and level of confidence needed.

For exploratory interviews or usability tests, recruit for relevant experiences and variation rather than chasing a generic number. For a quantitative estimate, define the population, expected precision, and acceptable uncertainty before collecting responses. A large sample from the wrong audience can still produce a misleading result.

Selection bias

Selection bias occurs when the people who respond differ systematically from the people who do not respond. For example, a feedback prompt shown only to power users may not describe the experience of new users.

Segment responses by relevant characteristics and use more than one feedback channel when you need a broader view.

Selection bias is about who enters the dataset. For example, a widget shown only to paying customers cannot tell you how free users experience activation. Record eligibility and exposure, compare respondents with the intended population where possible, and qualify conclusions with the segment actually represented.

Response bias

Response bias occurs when people’s answers are systematically influenced by the question wording, survey context, memory, desire to please, fear of consequences, or the way the response is collected. It affects what respondents say, even when the right people were invited.

For example, customers may give a more positive support rating if they believe a named agent will see the response. Reduce response bias with neutral wording, anonymous or confidential collection where appropriate, balanced answer choices, and questions about recent concrete behavior rather than hypothetical preferences.

Sampling bias

Sampling bias occurs when the people selected for a study or survey do not adequately represent the population the team wants to understand. It can happen when the sample comes from only one channel, customer segment, geography, plan, or usage level.

If you survey only power users about onboarding, the results may miss the experience of people who abandoned before becoming active. Define the target population, document who was reachable, recruit across important segments, and report which groups are missing or underrepresented.

Feedback analysis and operations

Sentiment analysis

Sentiment analysis classifies the emotional tone of feedback, often as positive, neutral, or negative. It can help teams scan a large volume of written responses and identify shifts that deserve closer review.

Sentiment is a signal, not a complete interpretation. A negative comment can contain a valuable feature request, and a positive comment can still reveal a usability problem.

tinyDialog can extract sentiment from text feedback so teams can filter responses and spot patterns more quickly.

Use sentiment analysis to prioritize review, not to make the final decision. A message such as “The new workflow is much faster, but I still cannot export the result” may be classified as positive while containing a critical product gap. Sample the underlying comments, check how the classifier handles your domain language, and track changes in sentiment alongside topics and customer segments.

Topic analysis

Topic analysis groups feedback by the subjects people mention, such as onboarding, pricing, performance, or a specific feature. It helps teams move from a long list of comments to recurring themes.

Topic labels should be reviewed against the original responses. Automated grouping accelerates triage, but human judgment is still needed to decide importance and next steps.

Define a useful level of detail before creating topics. “Product” is too broad to guide action, while “mobile checkout tax display” may be specific enough to assign to an owner. Merge synonyms such as “slow loading” and “takes forever,” but keep separate issues separate when they require different fixes.

Tagging

Tagging is the practice of adding consistent labels to feedback. Useful tags can describe the topic, customer segment, journey stage, sentiment, urgency, or status.

A small, shared tagging system is usually more useful than dozens of overlapping labels.

Start with a controlled set of fields—for example, topic, segment, journey stage, sentiment, severity, owner, and status. Document what each label means and review a sample of tagged responses regularly. If two teammates would tag the same comment differently, the taxonomy needs clearer definitions.

Feedback triage

Feedback triage is the process of reviewing, categorizing, prioritizing, and routing incoming feedback. Triage can separate bugs from requests, urgent issues from long-term opportunities, and one-off comments from recurring themes.

Prioritize with more than frequency. A low-volume accessibility issue, security concern, or revenue-blocking bug may matter more than a common request with a minor workaround. A simple triage record can include impact, affected segment, evidence count, urgency, confidence, owner, and next action.

Feature request

A feature request is a suggestion for a new capability, change, or improvement. A request is evidence of a user need, not automatically a product specification or a commitment to build the requested solution.

Look for the underlying job, problem, or desired outcome behind the requested feature. Multiple users may ask for different solutions to the same need.

Record the request in the customer’s language, then connect it to evidence and an outcome. For example, five requests for “Slack alerts” may represent a broader need to notice important events without checking the dashboard. That framing lets the team compare notifications, email, webhooks, and other solutions.

Bug report

A bug report describes behavior that does not work as intended. A useful report includes what the person expected, what happened instead, how to reproduce the issue, and any relevant device, browser, or account context.

Feedback widgets can collect the initial report; a follow-up workflow can then gather the technical details needed to reproduce it.

Make bug reports easy to act on by capturing the expected result, actual result, reproduction steps, frequency, severity, and environment. “The button does nothing” is a starting signal; “On Safari 18 on iPhone, tapping Save after editing a profile leaves the screen unchanged every time” gives an engineer a reproducible case.

Feedback loop

A feedback loop is the cycle of collecting input, analyzing it, making a change, and checking whether the change improved the experience. A strong loop also closes the loop with customers by communicating what was learned or changed.

Collecting feedback without reviewing it creates a feedback inbox, not a feedback loop.

Define the owner and review cadence before launching collection. A weekly review might classify new responses, merge duplicates, assign follow-up, and check whether recently shipped changes affected the original problem. Close the loop internally with a decision record and externally with an appropriate customer response.

Close the loop

To close the loop means to respond to feedback and explain what happened next. The response may be a thank-you, a clarification, a workaround, a product update, or an honest explanation of why a request is not currently planned.

Closing the loop builds trust and can improve the quality of future feedback.

The response should match the outcome. Thank someone for a useful report, explain when a bug was fixed, offer a workaround when one exists, and say clearly when a request is not planned. Avoid promising a roadmap date merely to make a dissatisfied customer feel better.

Churn signal

A churn signal is a behavior, comment, or survey response that suggests a customer may be at risk of reducing usage or cancelling. Examples include repeated frustration, failed onboarding, declining usage, unresolved support issues, or a response explaining that the product no longer meets a need.

Churn signals are clues, not predictions. Teams should investigate the underlying experience rather than treating a single response as a certain outcome.

Combine feedback with behavioral context before escalating a signal. A low NPS response from a customer who is actively adopting the product may require a different intervention from the same score paired with declining usage and unresolved support tickets. Record the evidence and next action, and avoid using sensitive personal data that is not necessary for the workflow.

Feedback collection and integration terms

Programmatic feedback

Programmatic feedback is feedback triggered by application logic or a defined user event. Examples include showing a survey after a user completes onboarding, reaches a usage milestone, or exits a cancellation flow.

Programmatic feedback makes it possible to ask a relevant question at a relevant moment. tinyDialog’s JavaScript and TypeScript SDK can be used to open a widget or submit feedback from an application workflow.

Define the triggering event and the audience explicitly. For example, show a two-question prompt to users who completed their first import, suppress it for users who saw the same prompt recently, and attach the import result as metadata. This produces more interpretable feedback than opening the same survey on every page view.

Trigger

A trigger is the event or condition that causes a feedback request to appear or be submitted. A trigger might be a button click, page view, completed workflow, feature use, user milestone, or custom application event.

Good triggers respect the user’s context. Avoid interrupting critical tasks or showing the same request so often that it becomes background noise.

Use a trigger that follows the experience being evaluated, not one that is merely easy to implement. A survey about checkout is usually more useful after checkout than at login. Test the trigger on mobile and with assistive technology, and define what happens when the event fires repeatedly.

Feedback frequency

Feedback frequency is how often a person or segment is asked for input. Frequency limits help prevent survey fatigue and reduce the risk that frequent responders dominate the dataset.

Set limits based on the importance of the event, the length of the survey, and how often the user encounters the relevant experience.

Frequency rules can be as simple as “one request per user per survey every 30 days” or as specific as “ask once after the first completed import and again only after a major workflow change.” Monitor response quality as well as response volume; more prompts do not necessarily produce more useful evidence.

Metadata

Metadata is additional information stored with a feedback response, such as page URL, survey ID, timestamp, browser, viewport, user identifier, plan, or feature context. Metadata helps teams segment and interpret responses without asking the user to repeat information.

Only collect metadata that is useful, appropriate, and communicated according to your privacy obligations.

Prefer stable, non-sensitive context over unnecessary personal data. A page path, feature name, plan tier, event ID, and timestamp may explain a response without storing the contents of a private account. Define retention and access rules, and make sure identifiers are handled consistently across connected systems.

Data connector

A data connector forwards new feedback responses from one system to another. It can send responses to a spreadsheet or database, notify a team channel, or start an automation.

tinyDialog data connectors can send responses to services such as Airtable, Slack, Discord, Zapier, n8n, and other systems through webhooks.

Connectors are most useful when they lead to a clear workflow. For example, route bug reports to an issue queue, send urgent account complaints to a support channel, and store tagged product feedback for roadmap review. Avoid forwarding every raw response to every tool; uncontrolled notifications make important signals harder to see.

Webhook

A webhook is an automated HTTP message sent from one system to another when an event occurs. When a user submits a tinyDialog response, a webhook can deliver the response data to an automation platform or custom endpoint.

Webhooks are useful when a team wants to connect feedback to a workflow that does not have a dedicated native integration. Platforms like Airtable, Slack, Discord, n8n, or Zapier support Webhooks as a way of connecting tinyDialog.

Design the receiving workflow for retries, duplicate deliveries, authentication, and failures. Include an event or response ID so the destination can safely process the same feedback more than once, and log failed deliveries for later review.

Feedback dashboard

A feedback dashboard is the place where responses are viewed, filtered, analyzed, and managed. A useful dashboard makes it easy to see recent responses, recurring topics, sentiment, segments, and unresolved follow-up work.

tinyDialog includes a dashboard for reviewing responses, with options to filter feedback and export responses as CSV.

A dashboard should help a team answer questions, not only display totals. Useful views include new unreviewed responses, themes by segment, low scores with comments, unresolved bugs, and feedback connected to a recent release. Show the sample size and time period beside every metric so trends are not interpreted without context.

How to use this glossary in a feedback program

Start with the decision you want to make, then choose the smallest research or feedback method that can inform it.

1. Define the audience and experience you want to understand.
2. Choose a focused question and an appropriate response format.
3. Place the survey or feedback widget close to the relevant moment.
4. Add only the metadata needed for useful segmentation.
5. Review responses by topic, sentiment, and user segment.
6. Share the finding, make a change, and measure what happens next.

For a quick start, you can create a tinyDialog survey, add a feedback widget to a website, or trigger feedback from JavaScript. You can also read our guide to programmatic feedback in SaaS.

Frequently asked questions about customer feedback

What is the difference between customer feedback and user research?

Customer feedback is the input people share about an experience. User research is the broader, structured practice of studying people to understand their needs, behaviors, and motivations. Feedback is one source of evidence within user research, alongside interviews, observation, usability testing, and analytics.

What is the best way to collect customer feedback?

The best method depends on the question. Use a short in-app survey or feedback widget for timely, scalable input; interviews and usability tests for depth; and passive sources such as support tickets and reviews for unsolicited issues. Combining methods usually gives a more complete picture.

What is the difference between CSAT, NPS, and CES?

CSAT measures satisfaction with a specific experience, NPS measures willingness to recommend, and CES measures how easy or difficult it was to complete a task. Choose the metric that matches the decision you need to make, and pair the score with context when you need to understand the reason behind it.

How can teams get more actionable feedback?

Ask one clear question at a relevant moment, keep the interaction short, leave room for an optional comment, and capture useful context such as the page or feature involved. Then review feedback by theme and close the loop with users.

Can tinyDialog collect both ratings and written feedback?

Yes. tinyDialog supports customizable survey and widget experiences, including rating-style prompts and text responses. Responses can be reviewed in the dashboard, exported, analyzed by topic or sentiment, and forwarded to connected tools.

Where should a feedback widget appear?

Place it where the feedback is most relevant: near the end of a documentation page, after a completed workflow, beside a feature that needs validation, or behind a clearly labeled feedback button. The right placement depends on the question and should not obstruct the primary task.

How often should you ask users for feedback?

Ask often enough to detect meaningful changes, but not so often that users experience survey fatigue. Set a frequency limit, prioritize important moments, and avoid repeatedly asking the same person about the same experience without a reason.

Final takeaway

Good customer feedback programs connect three things: a clear question, a relevant moment, and a path to action. Whether you call it a UX survey, a VoC program, an in-app micro-survey, or a feedback widget, the goal is the same: understand what people experience and use that evidence to make the next decision better.