Customer-service teams rarely need to choose between AI and people for every request. They need a routing policy. Use AI first for repeatable, low-risk requests supported by current information. Put a person first when the case is consequential, sensitive, ambiguous, or emotionally charged. Use a hybrid workflow when AI can gather facts or draft a response while a human makes the decision.
That rule applies to the request, not the channel. An authenticated order-status question may be suitable for a bounded AI response, while a billing dispute arriving in the same chat should go to billing support. The practical decision depends on four factors: the impact of an error, how predictable the request is, whether the necessary context is verified, and whether the next step is an answer or an account-changing action.
A generated answer is not permission to change an account, issue a refund, disclose a protected record, or make a legal, medical, financial, or security determination.
Automate only when the request, source information, and permitted next step are clear. Otherwise gather context or route to an accountable person.
How should customer-service teams choose between AI and a human?
Start by classifying the request rather than assuming that chat, email, or phone determines the right treatment. A single channel can contain a routine status check, a security report, and a high-impact financial dispute.
- Impact if wrong: Could an error affect money, access, safety, legal obligations, privacy, or customer trust?
- Predictability: Does the request follow a stable process, or does it require judgment, negotiation, or follow-up questions?
- Context completeness: Are identity, record ownership, current product details, and relevant history available and verified?
- Next-step authority: Is the task to explain or summarize, or to take an action that changes a customer record or account?
AI-first handling is appropriate when the answer is repeatable, the cost of error is low, and the supporting source is current. Human-first handling is appropriate when the case is high-impact, unclear, sensitive, or emotionally charged. Hybrid handling is appropriate when automation can collect facts, identify the likely issue, or prepare a draft, but a person must approve the consequential response or action.
These are operating recommendations, not performance guarantees. AI can respond quickly when the required information and permitted actions are available, but authentication, retrieval quality, system availability, and investigation requirements can change the result.
For teams defining these boundaries, AI agent design and implementation is a relevant service description. It is not evidence of a particular product capability or outcome.
Route by risk and predictability, not by channel
The framework below is an editorial operating model, not a vendor-published scoring system. Use the default lane as a starting point, then change it when authentication, record checks, risk, or ambiguity require a different route.
| Request or trigger | Default lane | AI’s bounded job | Validation and fallback |
|---|---|---|---|
| Order or delivery status | AI-first | Retrieve and explain a current status | Verify identity and ownership; route mismatches or conflicting data to order support |
| Password or access issue | Hybrid | Explain approved recovery steps | Use the verified recovery process; route suspected compromise or failed recovery to security support |
| Billing dispute or refund request | Human-led | Capture details and summarize the claim | A billing specialist verifies the transaction and owns any financial decision |
| Cancellation request | Hybrid or human | Identify intent and explain permitted steps | Apply the policy; route disputed fees, vulnerable customers, or exceptions to a person |
| Multi-step technical problem | Human-led or hybrid | Collect symptoms, version, and steps tried | Escalate when branches, evidence, or customer impact exceed the script |
| Outage update | Hybrid | Share an approved, current notice | Humans handle account-specific impact, uncertain status, and investigation |
| Legal, medical, financial, or security issue | Human-first | Capture only the minimum needed to route safely | Send to the designated specialist; do not automate a consequential determination |
For an account-specific response or action, require a verified customer identity, a matching target record, and an explicit authorization rule. Deterministic checks are better than generated text for hard boundaries such as whether an order belongs to the authenticated customer or whether an approval is present. AI can classify ambiguous language, but it should not override those checks.
Design the handoff as an explicit workflow
A handoff is a contract between the automated step and the person or queue receiving the work. Preserve the customer’s request, verified context, what automation tried, why it stopped, and who owns the next action. A transfer event alone does not mean the customer has been helped.
A hypothetical handoff record might contain the following fields. They are proposed implementation fields, not HubSpot-native fields:
{
"intent": "billing_dispute",
"risk_class": "high",
"source_document_ids": [],
"proposed_action": "summarize_and_route",
"human_approval_required": true,
"escalation_reason": "customer_disputes_charge",
"decision_timestamp": "2026-10-11T14:30:00Z"
}Before an action is taken, validate required fields and allowed values. A missing intent, invalid risk class, stale source, target-record mismatch, or unauthorized proposed action should fail closed to review. Phrase detection can support escalation for words such as “cancel” or “refund,” but it should not be the only route to a human because customers use varied language and keywords can appear in routine questions.
Four practical patterns for AI, human, and hybrid service
1. Authenticated order-status lookup: hypothetical AI-first workflow
Trigger and inputs: A customer asks for an order status through a supported channel. The request includes the message, an authenticated customer ID, and an order ID.
AI job and output: Classify the request as an order-status lookup and prepare a concise response from a current, permitted status source. A proposed output can include intent, risk_class, requested_order_id, and source_document_ids. The order system remains the source of record.
Validation and action: A deterministic check confirms authentication, customer-to-order ownership, lookup eligibility, and source freshness. Return only the verified status through the originating channel. Do not infer identity, change the order, or promise a delivery date absent from the source.
Exception owner: Missing authentication, mismatched ownership, unavailable status data, delivery disputes, and conflicting records go to the designated order-support queue. Measure completed lookups separately from repeat contact about the same order issue.
2. Billing dispute: human-led with AI intake support
Trigger and inputs: A customer disputes a charge, requests a reversal, or reports an unexpected billing outcome. Capture the original message, customer identifier, related invoice or transaction identifier, and channel.
AI job and output: Classify the likely dispute, extract customer-provided facts, and prepare a neutral summary. Mark uncertain or contradictory details as claims rather than facts. AI may identify a possible duplicate charge, but it must not decide liability, promise a refund, or execute a payment action.
Validation and action: Confirm that required identifiers exist and are linked to the correct customer. Attach the original message and summary to the support case, then route it to the billing-support owner. The specialist verifies the transaction, communicates the decision, and owns any adjustment.
Exception owner: Missing identifiers, conflicting account information, vulnerable-customer indicators, and requests involving payment security remain with the specialist for clarification and controlled handling. Track handoff completion and repeat contact about the issue rather than treating every billing ticket as a resolved case.
3. HubSpot customer-agent handoff: documented behavior
HubSpot documents customer-agent handoffs that can be configured as live, asynchronous, or no handoff. Destinations can include an inbox, Help Desk, specific users, teams, or workflows, subject to account conditions, seats, permissions, and credits. Documented default triggers include the agent being unable to answer, a visitor requesting a human, or the agent being paused. Custom handoff guidelines can change that behavior. See the customer-agent handoff documentation for current configuration details.
Operational sequence: Configure the trigger and destination, customize available, unavailable, and unassigned messages, and test both an available user and a team with no available user. Then inspect the resulting handoff status and ticket context in the account. HubSpot documents statuses including Pending, Awaiting Human Assignment, and Handed off.
Team-only routing can run even when no user is available. Assign an operations owner to monitor cases awaiting assignment and decide deliberately whether an unassigned chat remains open or closes. The documented workflow template named “Reassign Tickets for Customer Agent Handoff” is a starting template with editable placeholder actions, not a complete configured implementation.
4. Closed-ticket knowledge-base improvement: documented beta workflow
HubSpot documents a beta knowledge-base agent that can use closed-ticket conversations to identify content gaps and generate article drafts or suggested edits. Current documentation lists setup conditions including an existing knowledge base and at least five closed ticket records, along with applicable access, permission, and AI settings. The feature can be active in one knowledge base at a time. See the knowledge-base agent documentation for current requirements.
Operational sequence: Select the knowledge base and eligible ticket pipelines, review the proposed gap and source conversations, edit or dismiss the draft, and have the content owner approve any article before publication. A draft is not a published answer and does not prove that customer-facing automation uses only approved articles.
Exception owner: The knowledge-base owner resolves outdated instructions, factual conflicts, sensitive information, and product-version changes. Record the source conversations and review date so a later editor can assess provenance and freshness.
What HubSpot handoff and routing features actually support
HubSpot’s customer-agent documentation describes configurable handoff guidelines, handoff modes, destinations, availability messages, and handoff status values. The documented customer-agent workflow template can help begin a configuration, but its actions can be edited, added, or removed. Treat it as a starting point rather than a finished design.
Skill-based routing in Help Desk is a separate capability. Current documentation lists Service Hub Enterprise, a connected Help Desk channel, Service Seats for assigned users, and required permissions. The documented feature can use language, custom skills, ticket-property filters, rule priority, and distribution options. Confirm availability and configuration in the actual account before designing around it. HubSpot’s skill-based routing guide explains the documented prerequisites and controls.
A practical readiness path is to confirm the subscription, seats, permissions, and any applicable HubSpot Credits; connect the relevant channel; define triggers and destinations; test unavailable-agent behavior; and verify the ticket status, owner, and conversation context in the account. Help Desk tickets can contain multiple conversations, and replies to closed tickets can reopen the existing ticket. Test those behaviors before defining reporting rules. The Help Desk ticket documentation describes the relevant ticket and conversation behavior.
A handoff event is not an accepted case. Because team-only routing can run when no user is available, monitor unassigned and awaiting-assignment states and give a named owner responsibility for clearing them.
For help evaluating account configuration and operational fit, see HubSpot systems consulting. This service link is a resource for assessment, not evidence of a specific HubSpot feature or implementation result.
Measure resolution quality at the right data grain
Deflection volume alone cannot show whether a customer’s problem was solved. Define the unit, numerator, denominator, and time window before comparing AI and human handling. A Help Desk ticket may contain multiple conversations and may reopen, so ticket count is not a count of unique customer issues.
- Message: Measure response latency from an inbound customer message to the first reply, with channel and business-hours rules defined.
- Conversation: Measure time from the first request to the first human handoff, or the share of conversations with a completed handoff.
- Ticket: Count assignments, status changes, reopens, or handoffs at ticket level. Do not treat these as unique issues.
- Customer issue: Define an issue episode, such as one underlying order problem, and measure repeat contact within a stated window.
- Routing event: Measure rule matches, assignment, reassignment, and queue transitions separately from resolution.
For example, define conversation handoff time as the elapsed time from the first customer message in a conversation to its first human handoff. Define issue-level repeat contact as the share of resolved issue episodes with another contact about the same issue within seven days. Add successful resolution, customer effort or satisfaction where collected, and agent workload. None of these metrics should be inferred from raw ticket totals.
If an external data store records events from more than one worker, define what one row represents and use stable source identifiers at that grain. A possible key for an inbound observation is the source system plus immutable source-event ID. A conversation event can use the conversation ID plus message or event ID. A ticket event can use ticket ID plus event type and occurrence ID. An AI run needs a run ID and configuration or model version. A citation-level knowledge record needs an article or source-document ID plus a citation span or source reference.
These are illustrative integration designs, not HubSpot-published schemas. Do not use customer ID plus date as a unique key. Lookup-then-create is not race-safe when concurrent workers process the same event. Use a database-enforced unique constraint or a transactional upsert for the relevant key. The reviewed HubSpot documentation does not establish a general API idempotency guarantee for these proposed workflows.
Roll out the routing policy in controlled stages
Start with one low-risk request type and name the owners for routing policy, source content, escalation, and monitoring. Set escalation timing from channel service targets, issue risk, and observed customer effort. A two-to-five-minute threshold can be tested as an operational hypothesis, but it is not a universal standard and may not suit asynchronous, regulated, or complex support.
Expand only after the human fallback works under test and outcome measures show acceptable quality for that request category. Review results by intent and risk, then revisit the policy when products, source content, permissions, or account configuration changes.
- A routine request completes from a current source and returns the correct record.
- Missing identity, stale information, and ambiguous intent stop automation and reach the named owner.
- An explicit request for a person reaches the intended destination with the original context preserved.
- An unavailable-agent test creates visible, monitored unassigned work rather than a silent dead end.
- A repeated bot loop or repeat contact can be identified at conversation or issue grain.
- A reply to a closed ticket and any resulting reopen are represented correctly in reporting.
The strongest hybrid model is not AI first for everything. It is a controlled division of responsibility: AI handles predictable work and prepares context, while people retain authority for judgment, negotiation, accountability, and consequential decisions.