To identify customer needs, combine what customers say with what they do, classify the underlying outcome or obstacle, validate the interpretation, assign an owner, and measure the response. For example, “I can’t find the invoice, and I’m frustrated” contains a possible information-access need and an expression of negative sentiment. Check the ticket and account context before treating that interpretation as a finding.
A practical operating model moves from evidence to a reviewed decision, then to a product, service, content, or support action. Surveys are one input, not a complete diagnosis. Interviews, support records, product behavior, customer context, reviews, search queries, and supported social interactions can reveal different parts of the problem.
This guide focuses on the operating details that are easy to lose: preserving source evidence, separating sentiment from inferred need, using deterministic rules before AI, routing uncertain cases to review, and keeping response-level records distinct from customer-level summaries.
What customer needs are, and what they are not
A customer need is a problem to solve, outcome to achieve, or condition required for someone to use or buy an offering. It is not the same as the language or emotion used to express it.
- Need: the outcome or condition required, such as access to an invoice.
- Pain point: friction that makes the outcome difficult, such as not knowing where the invoice is stored.
- Expectation: a standard the customer anticipates, such as receiving confirmation after a request.
- Preference: an option the customer favors, such as receiving an invoice by email instead of downloading it.
- Sentiment: the tone or expressed feeling, such as frustration or relief.
One statement can contain several signals. Preserve the customer’s words and source context, then record your interpretation separately. A negative comment alone does not establish its cause, prove churn risk, or identify a business outcome.
A feedback signal is evidence to interpret, not yet a customer need or a decision to act.
A practical taxonomy: product needs and service needs
Use a controlled vocabulary to organize evidence, not to replace the customer’s own words. A response may fit more than one category. Define each label with examples and provide an “other” or “unclear” option so reviewers are not forced into a poor fit.
Product needs
- Functionality: the offering performs the task the customer needs.
- Price: the cost and terms fit the customer’s circumstances.
- Convenience and efficiency: the solution is accessible and reduces unnecessary effort or time.
- Experience and design: the interaction and presentation work for the customer.
- Reliability and performance: the offering works consistently and at a useful level.
- Compatibility: the offering works with existing tools, products, or processes.
Service needs
- Empathy and fairness: the customer is heard and treated consistently.
- Transparency and information: the customer can understand terms, progress, and next steps.
- Control and options: the customer has appropriate choices and can influence the interaction.
- Identity, security, and community: the experience respects customer values, protects information, and supports belonging where relevant.
For example, “I need this to work with our accounting tool” may indicate compatibility. “I don’t know what happens after I submit the request” may indicate an information or transparency need. Keep the original statement beside either label because the label is an interpretation, not a replacement for evidence.
Collect evidence from more than surveys
Different sources answer different questions. A survey can ask directly about effort or satisfaction. An interview can reveal circumstances and workarounds. A support record can show where a process breaks down. Product behavior can show what customers do. Reviews, search queries, CRM context, and supported social interactions can add language and journey context. None of these sources alone represents every customer or explains every cause.
| Evidence source | Useful for | Cannot establish alone |
|---|---|---|
| Surveys | Direct ratings and structured answers | Why a score was given or how nonrespondents feel |
| Interviews | Context, workarounds, and decision factors | How common a theme is across the customer base |
| Tickets and conversations | Repeated friction, unresolved questions, and journey context | Problem prevalence outside customers who contacted support |
| Usage, reviews, search, and social interactions | Observed behavior, recurring language, and public feedback | Full intent or the cause of behavior |
For each observation, retain its source record ID, timestamp, channel, and relevant ticket, product, or journey context. Associate a customer or account only where permitted and reliable. A low survey score is evidence of dissatisfaction, not a diagnosis of its cause or a representative measure of all customers.
HubSpot documents Customer Effort Score support surveys that can be triggered when a ticket closes, with immediate or delayed delivery and configured follow-up actions for response bands. A support survey is sent only once per ticket. Customer Satisfaction surveys can be delivered by email, chat, or a webpage with HubSpot tracking code. These survey features require Service Hub Professional or Enterprise and an assigned Service Hub seat. Email delivery has additional marketing access and permission requirements. See the official guidance for support survey setup and CSAT survey delivery.
HubSpot’s social tools also have defined coverage limits. Keyword feeds cover X, show posts from after feed creation, may take up to four hours to update, and display only the past seven days of X activity. The social sentiment feature categorizes qualifying comments and mentions as positive or negative; text under 40 characters or with insufficient information can remain untagged. These tools can contribute evidence, but they are not comprehensive listening across every network. See social stream limits and documented sentiment behavior.
Turn raw feedback into a decision
Analysis should make it possible to challenge an interpretation without losing the evidence. Keep the observed statement, inferred need, and proposed action as separate items. When customers request conflicting solutions, compare the outcomes and affected segments rather than choosing the loudest feature request.
This is a proposed team decision framework, not a universal scoring formula. Use criteria such as customer impact, affected customers, severity, strategic fit, feasibility, and confidence in the evidence. If a theme is weakly supported, gather more evidence instead of presenting it as settled. In HubSpot, survey-response properties are distinct from contact properties and are retained per response. They can be used in supported segments, workflow enrollment triggers, and custom reports. See survey-response property documentation.
Use AI for ambiguous feedback, with a review gate
Start with deterministic rules when a value is explicit: a selected survey answer, ticket status, product SKU, known entitlement, or error code. Validate that value against an allowed list before it enters a report or CRM field. Use AI as a bounded aid for open-text categorization, summarization, clustering, or candidate theme discovery, not as an authority on what a customer “really” needs.
A negative comment signals dissatisfaction but may not reveal whether the cause is price, access, reliability, or something else. Classify tone separately, then review the surrounding evidence before assigning a need.
For example, a rule can map a selected survey option of “billing” to a controlled category. AI may propose an “information” label for “I could not tell when the credit would appear.” A reviewer approves or corrects the proposal before it changes a durable customer profile or triggers consequential treatment.
The following is an illustrative proposed output shape, not a HubSpot schema. The source ID points to the original event, and sentiment remains separate from the inferred need.
{
"source_record_id": "response_illustrative_104",
"need_category": "information",
"evidence_text": "I could not tell when the credit would appear.",
"sentiment": "negative",
"confidence": "review",
"review_status": "unreviewed",
"model_version": "example-model-version",
"classified_at": "2026-10-12T14:30:00Z"
}Validate the category against the current taxonomy, check that the source text is permitted for processing, and keep a human review path for low-confidence, conflicting, sensitive, or consequential cases. Record the model and prompt version if the classification may affect customer treatment. Redact or exclude sensitive data under your access and retention policy.
Move validated needs into product, service, and self-service improvements
Send each approved finding to the owner able to change the underlying experience. The following table describes proposed operating patterns. It does not claim that HubSpot provides a turnkey implementation of every step.
| Trigger and input | AI job or decision | Validation and destination | Fallback |
|---|---|---|---|
| Closed ticket and eligible recipient | No AI is required. Collect a documented support survey response. | Distinguish sent, delivered, and submitted states where available. Retain ticket and response identity for support reporting. | Support operations handles delivery exceptions; the support lead follows up on low scores or escalation language. |
| New survey response, ticket message, or approved feedback event | Use deterministic mapping for explicit choices. Use AI only to propose labels or themes from permitted open text. | Validate source identity, taxonomy, provenance, and review status before writing to a review queue or approved CRM field. | Send low-confidence, contradictory, sensitive, or consequential cases to customer insights or support operations. |
| Repeated, validated question theme | Optionally cluster similar questions or draft an outline from approved material. | Subject-matter review verifies product version, plan, region, and access rules before publishing a knowledge-base article. | The content owner rejects or revises the draft; support operations handles unresolved customer cases. |
| Conversation on an eligible configured channel | The customer agent can use configured website or file sources, ask clarifying questions, provide sources where enabled, or route to a human based on confidence. | Test source freshness, permissions, citations, channels, and escalation rules before production deployment. | Support owns the reassigned conversation; the agent administrator maintains sources and routing. |
Product and support operations
- Product: route a validated capability or compatibility need to the product backlog with affected segments, evidence references, and an acceptance measure.
- Support operations: route repeated process friction to the team that owns the workflow, script, routing, or policy. Define an exception path for unresolved or sensitive cases.
Content and self-service
For repeated how-to questions, cluster the source tickets, draft against approved material, verify product version and access rules, obtain subject-matter approval, and assign an owner and review date. HubSpot knowledge bases support article publishing and visibility controls, including public, access-group, and SSO-required visibility. The documented feature requires Service Hub Professional or Enterprise, an assigned seat, and relevant permissions. See the knowledge-base article guide.
HubSpot’s customer agent can use configured website or file sources to answer questions, provide verifiable sources where enabled, ask clarifying questions, or reassign conversations to a human based on confidence. Documented deployment channels include Facebook, WhatsApp, calling in beta, live chat, forms, email, and custom channels. Eligible subscriptions and HubSpot Credits apply, and channel and routing options should be checked in the target account. Treat confidence as a routing signal, not a calibrated probability. Keep source content current and define human escalation for account changes, refunds, authentication, legal or safety-sensitive questions, and unresolved cases. See customer-agent setup, content-source management, and channel deployment.
Publishing an article or deploying an agent does not by itself prove that tickets, costs, or staffing needs have fallen. Track customer outcomes separately from implementation completion.
Measure whether the response worked
Set a baseline before the change and choose a measure tied to the need. For a support improvement, that might be repeat contact about the same topic, completion of a defined task, response-level effort ratings, or time to resolution. Record implementation measures, such as an article published or routing rule activated, separately from customer outcomes.
For a support change, compare defined pre-change and post-change periods using the same ticket-topic definition, and report survey response counts alongside scores. Check for seasonality, product changes, and differences in who responded. A score change alone does not establish that the change caused the result. Retention, lifetime value, and churn have other possible causes and should be measured rather than assumed.
Implementation details that prevent misleading records
Choose the data grain before choosing identifiers. One survey submission is one response-level record. If one contact submits two responses, retain both records and link each to its own ticket and submission time where available. A contact-level figure such as “negative responses in the last 90 days” is a separately calculated aggregate, not a replacement for those responses.
Keep other grains separate too. One model observation is one input processed in one run. One citation is one reference attached to an observation. One daily metric is an aggregate for a defined entity, period, and metric definition. Do not store a daily summary or share-of-voice value as if it were an individual customer event.
Illustrative response records:
- response_id_1 | contact_27 | ticket_81 | 2026-10-12T09:15:00Z
- response_id_2 | contact_27 | ticket_96 | 2026-10-12T16:40:00Z
Separate aggregate:
- contact_27 | negative responses in trailing 90 days | 2Use a stable source event ID as the proposed event key, such as source_system + source_event_id. Do not use contact ID plus date when the same person can submit more than once in a day. For model observations, include an execution identifier, such as input_id + run_id. For citation records, use an observation identifier plus citation sequence when repeated citations matter. For aggregates, include the entity, period, metric-definition version, channel, and model or engine where relevant. These are proposed schema patterns, not HubSpot-published fields.
A search-then-create sequence can duplicate records when two workers process the same event concurrently. Enforce uniqueness in the integration database or use a transactional upsert where supported. Record processing status, handle retries, and route failed validation to an exception queue. HubSpot documents updating an object through a configured unique custom property, but that does not make a multi-writer integration race-safe. Confirm that the target account exposes the required data and permissions before building a survey-response API or export path. The available documentation does not establish a universal endpoint for every feedback field. For new integrations, select a supported date-based API version and verify scopes in the account. See HubSpot’s ticket update reference, unique-identifier update guidance, and API version overview.
- Source identity and row grain are explicit.
- A database-enforced unique key or transactional upsert handles concurrent processing.
- The proposed category is in the current allowed taxonomy.
- Evidence, model provenance, and classification status are retained.
- The review status meets the write-back rule.
- A newer human-entered value cannot be silently overwritten.
When you need to validate a CRM data model, permissions, and account-specific feature availability, HubSpot systems consulting can help assess the implementation requirements. For broader record design and ownership decisions, see CRM systems consulting. If the workflow includes bounded classification or customer-facing automation, AI agent implementation is relevant to source, routing, and review design.
HubSpot feature conditions and documentation checked October 12, 2026. Plan, seat, credit, permission, channel, API-scope, and version availability can change. Confirm them in the target account.