Build a customer care program by defining which customer signals require action, assigning each signal to a named owner, preserving the original interaction as an attributable record, and measuring what happens next. For example, a low customer-effort survey response can trigger a check for an open support case: add the response to the active case if one exists, or create a customer-success follow-up if it does not.
Customer care is the operating layer that adds context, judgment, continuity, and relationship handling to service and success interactions. It does not replace resolving the issue. Start with a small number of signals and clear routes. Add automation only after the team can explain the data, owner, destination, and exception path at each step.
This guide treats customer care as an operating design problem rather than a standalone department or an AI product feature. The workflows and schemas are proposed designs. HubSpot and Make documentation is used to describe relevant capabilities and constraints, not to imply that either platform supplies a complete customer-care template.
What a customer care program does
Customer service resolves a case. Customer success helps a customer adopt a product and achieve intended outcomes. Customer experience looks across the broader journey. Customer care shapes how people are treated across those interactions, including whether teams understand prior context, respond appropriately, and follow through.
That makes care a shared operating principle with accountable owners, not necessarily a separate team. For each incoming signal, decide whether it needs immediate service resolution, a customer-success follow-up, specialist escalation, or no additional action. Name the owner before automating the route. HubSpot’s customer-care overview provides conceptual framing; the workflow and data model below are an independent design.
Choose care signals and define their data grain
Begin with one or two observable signals that can lead to a specific action. Examples include a low survey score, repeated contact about the same issue, a service failure, or a permitted product-usage event that indicates a need for help. Avoid treating a vague label such as “unhappy customer” as a trigger until the team defines how it is produced and what action it requires.
Before choosing a CRM object or integration key, define what one record represents. A ticket is one case. A survey response is one response instance. An AI classification is one observation from one processing run. A citation is one evidence item. A customer-health score is an aggregate calculated from other records. Keep these grains separate, and do not overwrite historical responses with a latest sentiment value.
HubSpot documents feedback-submission properties for segmentation, workflow enrollment, and reporting. Its survey responses are represented separately from contact properties, which supports retaining each response rather than treating sentiment as one permanent contact attribute. See the feedback-submission property documentation.
| Record | One row means | Identifier | Aggregation scope |
|---|---|---|---|
| Case | One support issue | Ticket ID | Case |
| Survey response | One submitted response | Survey response ID | Response |
| Classification | One model observation from one run | Source event ID plus run ID | Observation |
| Health summary | One calculated period summary | Account ID plus time window | Account and period |
A proposed event envelope for routing might include source_system, source_event_id, event_type, occurred_at, customer_id, account_id, channel, raw_text_uri, and processing_status. If classification is used, retain its provenance separately with model_version, prompt_version, policy_version, and human_review_status. These are illustrative design fields, not a vendor-defined HubSpot schema.
A customer is not a data grain: preserve each ticket, survey response, AI observation, and evidence item as its own attributable record, then calculate customer-level summaries separately.
For CRM design, record the object, unique identifier, ownership rule, association meaning, and retention period before building routes. CRM systems consulting can help teams assess record structure and ownership without implying that a prebuilt customer-care workflow exists.
Turn a signal into an owned follow-up
Use structured checks for facts that already exist in records. Identity, communication eligibility, subscription status, duplicate detection, open-case status, and configured risk terms should be determined from reliable fields or rules, not inferred by a language model. AI can help interpret ambiguous wording, summarize context, extract evidence, or suggest a route. It should not independently authorize compensation or change an account.
Consider a hypothetical feedback-response design. A new feedback submission enters a workflow when the relevant object and subscription support that action. The workflow validates the response ID and timestamp, resolves the customer using a stable identifier, checks communication eligibility and active escalations, and then selects the destination. If an open case exists, add the response context to that case or its owner’s follow-up. If none exists, create a customer-success task linked to the response. Route security, fraud, legal, or sensitive account-change indicators to a specialist queue instead.
HubSpot documents workflow actions, but availability varies by object and subscription. Ticket and feedback-submission property actions require Service Hub Professional or Enterprise. Check the current workflow action documentation before configuration. Property-matched associations require exact, case-sensitive matches for supported property types, so use normalized identifiers rather than free-text company names. See HubSpot’s association guidance.
Illustrative classification contract
If an external AI service is used, define and validate a narrow output contract before any CRM write. The following fields are illustrative and are not HubSpot-defined:
{
"care_signal": "service_failure",
"urgency": "medium",
"confidence": 0.86,
"evidence_spans": [
"I had to contact support twice to get the issue fixed."
],
"recommended_route": "customer_success",
"needs_human_review": true,
"model_version": "illustrative-model-version",
"prompt_version": "care-routing-v1"
}Reject invalid enum values, confidence outside the defined range, or a high-impact classification without evidence. Missing or ambiguous identity should stop automatic routing and enter an enrichment queue. Save the raw response, derived classification, and final human decision as distinct records or fields with appropriate access controls.
Practical workflow patterns
The patterns below show how to turn the design into operating decisions. They are proposed architecture examples, not published HubSpot or Make templates.
| Trigger | AI job or rule | Validation | Action and fallback |
|---|---|---|---|
| Low feedback response | Rule checks score and open-case status. AI may summarize free text. | Validate response ID, customer match, eligibility, recency, and risk terms. | Update the active case, or create a success task. Quarantine missing matches. |
| Support message mentioning account takeover | Deterministic security rule takes priority. AI may extract evidence. | Require valid risk value and quoted evidence. Do not allow model-only routing. | Create or update a security review item linked to the source case. Notify incident response. |
| Repeated delivery of one event | No AI needed. Construct a key at the action grain. | Use destination-enforced uniqueness or transactional upsert. | Upsert where supported. Preserve failed writes for reconciliation. |
| Supported policy question | Customer agent answers from approved content. | Check source freshness and sensitive-topic rules. | Respond or perform a configured action. Hand off when content is insufficient or a person is requested. |
Prevent duplicate follow-ups and preserve CRM ownership
Choose a key that identifies the action at the correct grain. For one action per source event, a proposed key is source_system + source_event_id + action_type. If each AI run is retained as a separate observation, include run_id, model_version, and prompt_version. If each citation is a separate record, include a citation ID. A customer ID and date are not enough because one customer can submit multiple responses, have several cases, or generate several model observations on the same day.
A lookup-then-create sequence can fail under concurrent processing. Two runs may both find no record and then both create one. Where concurrent writes matter, prefer a destination-supported unique-property upsert or a database-enforced unique constraint. HubSpot documents batch upsert by a configured unique property for its documented custom-object endpoint. That does not establish identical support for every CRM object or plan.
Make Data Stores support key-based existence checks, but the documentation does not establish a simple check as a race-safe distributed lock. Make retry handlers also do not make repeated side effects idempotent. Preserve the source event and processing status even when a destination write fails.
A successful pre-check does not prove uniqueness when runs can overlap. Use a destination-enforced unique key or transactional upsert where available. If the destination cannot enforce uniqueness, retain the source event and route uncertain writes for reconciliation instead of claiming that a pre-check prevents duplicates.
Consult the documented HubSpot custom-object upsert endpoint for its unique-property requirements. Make’s Data Store documentation covers keyed existence checks, while its error-handling guidance explains retry behavior. Make automation consulting is relevant when designing the integration and recovery path, not as a substitute for destination-side uniqueness.
Set human review, privacy, and AI boundaries
Use rules or required human approval for refunds, credits, cancellations, account ownership changes, security concerns, legal threats, and sensitive-data updates. Use AI for classification, summarization, evidence extraction, and suggested routing when language needs interpretation. Low confidence, conflicting observations, or missing evidence should enter a human queue.
Keep the original message, derived classification, and final human decision distinct. Restrict access to potentially sensitive customer content and apply the organization’s retention rules. If the current CRM value changed after classification, compare the current value with the value used during classification and abort or escalate rather than blindly overwriting it.
For a narrow customer-agent use case, HubSpot documents supported content sources, configured actions, and handoff under configured conditions. Start with current, approved content and a limited set of permitted actions. HubSpot warns that private content may be used without being cited and advises against adding confidential or sensitive customer data to content sources. Its customer-agent reporting uses a 72-hour resolution evaluation window, and manual workflow assignment alone does not necessarily qualify as a human handoff. Review the content-source guidance and customer-agent behavior and resolution definitions before using those metrics.
For example, a returns question may be answered from an approved, current returns policy. If the source is missing, the customer requests a person, or the conversation involves a sensitive account change, route it to the configured human queue. Record whether the outcome was an answer or a qualifying handoff. Do not count a routine task assignment as proof that the agent handed the conversation to a person.
Plan entitlements, supported objects, API behavior, credits, and product documentation can change. Verify the applicable requirements during implementation. HubSpot systems consulting can support configuration planning where object and subscription constraints affect the design.
Measure care without confusing activity with outcomes
Pair operational measures with customer and business outcomes. Operational measures can include time to first meaningful response, repeat contacts about the same issue, reopened cases, and follow-up completion. Customer measures may include effort or satisfaction. Business measures may include retention or renewal results. A response or resolution metric helps diagnose process friction, but it is not by itself evidence of empathy, loyalty, or lifetime value.
Set a baseline, define the customer segment, and choose an observation window before comparing results. For one segment receiving follow-up after low-effort responses, compare follow-up completion and repeat-contact rate over a defined period, then review the relevant renewal outcome. A change after launch does not establish that the program caused the change.
Track survey ID, response ID, score, date, and source at response grain. Calculate account-level sentiment or health separately using a documented rule and time window. Do not mix response-level measures with account-period aggregates or contact-level CRM events in the same metric.
A practical launch sequence
Start with one journey, one or two observable signals, and a named human owner for each outcome. Document identity rules, record grain, eligibility checks, escalation conditions, and the system of record before enabling automation. Test with historical or synthetic events, including missing identifiers, duplicate delivery, an active escalation, low-confidence classification, conflicting model runs, and API failure.
- Is there one clearly defined trigger and record grain?
- Does every route have a named owner and destination system?
- Does the event key identify the action, observation, or citation at its actual grain?
- Can the destination enforce uniqueness or support a transactional upsert for concurrent writes?
- Do deterministic identity, eligibility, and escalation checks run before optional AI suggestions?
- Does a human queue own missing, conflicting, low-confidence, or high-impact cases?
- Can the team measure a baseline and inspect exceptions after launch?
Launch with a limited route and monitor missed handoffs, duplicate actions, stale source content, and unresolved exceptions before adding signals or expanding AI permissions. A sound first release has one trigger, one owner, one destination action, an auditable source record, and an exception queue that someone is responsible for reviewing.