Customer Intent Taxonomy & Slot Schema Architect

Customer Intent Taxonomy & Slot Schema Architect helps conversational-AI, customer-support, NLU, CRM, automation, service-design, product, analytics, and contact-center teams build a rigorous semantic architecture for customer-service systems.

The skill defines:

Customer intents Intent families Sub-intents Issue categories Task categories Informational requests Transactional requests Account-specific requests Urgent intents Sensitive intents Fallback intents Unsupported requests Ambiguous requests Multi-intent requests Compound requests Entities Entity attributes Required slots Optional slots Conditional slots Derived slots Confirmation slots Authorization slots Evidence slots Context slots System-retrieved slots Sensitive slots Validation rules Normalization rules Authentication rules Authorization rules Routing rules Escalation conditions Completion criteria Conversation states Annotation standards Testing requirements Governance controls

The skill can support:

Customer-service chatbots Voice agents Virtual assistants Email triage Ticket classification Automated routing Agent-assist systems Self-service portals Help-center search Case-creation workflows CRM intake Support analytics Intent-classification models Natural-language-understanding systems Retrieval-augmented support assistants Omnichannel support platforms AI customer-service agents

The architecture begins with service discovery.

It defines:

What the support service can resolve What the service can explain What it can diagnose What it can transact What it can route What it must escalate What it must reject What it must redirect What requires authentication What requires authorization What requires specialist handling What is unavailable by channel What is restricted by region What is outside the supported product scope

The agent maps customer goals using real customer language rather than beginning with internal departments.

Examples of customer goals include:

Reset my password Restore access to my account Understand a charge Update my payment method Cancel my subscription Delete my account Check my order Report a missing delivery Request a refund Report a device problem Troubleshoot synchronization Change my plan Report an outage Transfer account ownership Remove a user Export my data

The skill distinguishes among:

Intent: What the customer is trying to accomplish now.

Entity: The object, record, product, account, transaction, date, location, device, or other structured information connected to the intent.

Slot: A named piece of information required or useful for fulfilling the intent.

Context: Information that influences the workflow but does not define the goal.

Severity: The urgency or impact of the request.

Channel: Where the interaction occurs.

Root Cause: Why the issue happened.

Workflow Status: Where the case currently sits.

Outcome: How the interaction ended.

These dimensions remain separate so the taxonomy is stable, useful for analytics, and operationally accurate.

Intent labels follow clear customer-goal naming conventions such as:

reset_password restore_account_access update_payment_method dispute_charge cancel_subscription request_refund check_order_status report_delivery_issue report_device_failure troubleshoot_sync_issue change_service_plan request_data_export

The skill avoids weak labels such as:

Billing Account Technical Problem Issue Support Request Other Question Complaint

Broad labels may still be used as parent domains, but not as substitutes for operationally distinct customer goals.

The agent can create hierarchical taxonomies such as:

Domain → Intent → Sub-intent → Workflow Variant

Example:

Billing → dispute_charge → duplicate_charge → unrecognized_charge → incorrect_amount → failed_refund → tax_or_fee_question

The hierarchy is kept only as deep as necessary for:

Different workflows Different required information Different authorization Different routing Different escalation Different legal or policy treatment Different completion criteria Meaningful analytics

The skill creates a complete intent record for every supported intent.

Each record can include:

Intent identifier Canonical label Display name Parent intent Definition Customer goal Included requests Excluded requests Positive examples Negative examples Hard negatives Confusion pairs Required slots Optional slots Conditional slots Derived slots Sensitive slots Authentication requirements Authorization requirements Routing Escalation Fallback behavior Completion criteria Analytics category Version Status

Inclusion criteria define what belongs in the intent.

Exclusion criteria define what does not belong.

For example:

Intent: cancel_subscription

Included: Requests to stop a recurring subscription immediately or at the end of the current billing period.

Excluded: Pause subscription Downgrade plan Delete account Dispute renewal charge Request refund Turn off automatic renewal without canceling access where the workflow differs

The skill identifies confusion pairs.

Common examples include:

cancel_subscription versus delete_account request_refund versus dispute_charge reset_password versus restore_account_access check_order_status versus report_delivery_issue device_setup versus troubleshoot_device update_payment_method versus payment_failed report_service_outage versus troubleshoot_local_connectivity request_data_export versus close_account change_plan versus add_feature warranty_claim versus repair_request request_invoice versus billing_question complaint versus escalation_request

For every confusion pair, the skill can document:

Shared customer language Intent A Intent B Operational difference Required slot differences Workflow differences Routing differences Separating condition Minimal disambiguation question Evidence requirements

The agent asks the smallest possible question that separates the leading candidates.

Weak disambiguation: Please explain your issue in more detail.

Strong disambiguation: Are you trying to cancel the subscription, delete the account, or dispute the latest renewal charge?

The skill audits intent overlap.

It evaluates:

Whether one utterance reasonably matches several labels Whether the difference changes the workflow Whether different information is required Whether different teams own the request Whether the risk differs Whether the customer outcome differs Whether a simple question can separate the candidates Whether two labels should be merged Whether one broad label should be divided

Intents are merged when their distinction does not change:

Workflow Required information Routing Authorization Escalation Customer outcome Completion criteria

Intents are split when the distinction changes:

Risk Policy treatment Authentication Authorization Required slots Workflow Routing Service level Completion Customer communication

Sub-intents are used when:

The parent customer goal is stable Variants share a common workflow Variants require distinct branches The distinction improves analytics The system can reliably separate them The variants have different slot requirements or outcomes

The skill does not create a separate intent for every error code, product model, customer type, or causal phrase when these can be represented as entities or context.

For example:

Intent: troubleshoot_service_error

Entity: error_code

Instead of:

error_501 error_502 error_503

The skill supports compound requests.

Example:

Customer statement: I cannot log in because my old phone still receives the verification code.

Architecture:

Primary intent: restore_account_access

Contributing condition: unavailable_mfa_device

Entity: authentication_method

Slot: previous_device_available = false

The agent avoids converting every contributing condition into a separate intent.

The skill supports multi-intent conversations.

Example:

Customer statement: My bill is wrong and I also need to change my payment card.

Detected intents:

dispute_charge update_payment_method

Multi-intent strategies can include:

Sequential resolution Parallel case creation Primary and secondary intent Urgent intent first Dependent intent first Customer-selected order Specialist handoff

A multi-intent record can include:

Detected intents Primary intent Priority reason Dependencies Resolution order Shared slots Separate slots Customer confirmation Separate case requirements

The system should not force two valid customer goals into one intent when both require action.

The agent designs fallback architecture.

Fallback categories can include:

Low-confidence fallback Unsupported-intent fallback Missing-context fallback Out-of-domain fallback Policy-restricted fallback Unavailable-workflow fallback Language fallback Channel-limitation fallback Repeated-failure fallback Safety fallback Security fallback

Each fallback can define:

Trigger Customer-facing message Recovery question Maximum attempts Preserved context Escalation condition Analytics label

The skill does not use one generic fallback for every failure.

Fallback recovery can:

Present likely categories Ask a focused question Summarize what is already understood Preserve collected information Offer a human-support path Create a support case Route to a specialist Explain unsupported scope Provide an approved alternative

Unsupported requests are classified separately from misunderstood requests.

Unsupported categories can include:

Unsupported by product Unsupported by policy Unsupported by channel Unsupported by region Authentication missing Authorization missing Specialist authority required Harmful or prohibited request Unrelated request Workflow not implemented

Each unsupported-request record can define:

Reason What the service can do Approved alternative Routing Escalation Customer message Analytics label

The skill creates an entity catalog.

Possible entities include:

Account Customer User Organization Product Device Service Subscription Plan Order Delivery Invoice Payment Transaction Refund Case Contract Date Time Location Region Language Error code Authentication method Communication channel Status Reason Evidence reference

Every entity can define:

Entity name Description Examples Canonical format Synonyms Source Validation Normalization Sensitivity Retention Intents using the entity

Entity types can include:

Categorical Numeric Monetary Date Date-time Duration Identifier Boolean Location Person Organization Product Device Transaction Account Service Status Reason Channel Evidence reference Free text

The skill builds detailed slot schemas.

A slot is a named value required or useful for the workflow.

Examples include:

account_id organization_id product_name device_model operating_system order_number invoice_number transaction_id payment_date subscription_plan error_code issue_start_time affected_users refund_reason delivery_address authentication_method

Slot categories include:

Required Slots: Always required for a defined workflow stage.

Optional Slots: Useful but not mandatory.

Conditional Slots: Required only when a defined condition is true.

Derived Slots: Calculated or obtained from another trusted source.

Confirmation Slots: Values that require confirmation.

Authorization Slots: Values proving authority or role.

Evidence Slots: References to supporting records.

Context Slots: Information that improves understanding.

System Slots: Values retrieved from authoritative systems.

Sensitive Slots: Values requiring special protection.

Every slot record can contain:

Slot name Display label Description Data type Requirement status Requirement condition Source Validation rule Normalization rule Confirmation rule Sensitivity Masking Retention Fallback behavior Intents using the slot

The skill applies the minimum-necessary principle.

A slot is required only when necessary to:

Identify the correct record Determine eligibility Establish authorization Choose the correct workflow Perform the requested action Assess risk Satisfy policy or legal requirements Verify completion Route correctly Escalate safely

The agent does not require information merely because the organization traditionally collects it.

Conditional-slot logic can be expressed explicitly.

Example:

If intent = troubleshoot_device: product_name is required.

If product_category = hardware: device_model is required.

If safety_indicator = true: stop routine troubleshooting and route to the approved safety process.

If intent = request_refund: transaction_id or alternative transaction locator is required.

If payment_method = bank_transfer: additional evidence rules may apply.

If customer_type = business: organization_id may be required.

The skill distinguishes slot-value states:

Unknown Not Provided Not Applicable Customer Reported System Verified Inferred Confirmed Invalid Conflicting Expired Redacted Unavailable Blocked

Unknown and not applicable are never treated as equivalent.

Validation rules can include:

Format Length Range Allowed values Checksum Date logic Cross-field consistency System existence Entitlement Ownership Status Freshness Uniqueness Regional validity Product compatibility

Each validation rule can define:

Slot Rule Validation source Error message Recovery prompt Escalation path

Cross-slot validation can check:

Refund date follows payment date Invoice belongs to account Device model belongs to product family User belongs to organization Selected plan is available in the region Payment method is supported by account type Contract end date follows start date Error code is compatible with product version Order number matches the selected customer

Normalization rules can cover:

Dates Time zones Currencies Phone numbers Email addresses Product names Model names Plan names Order numbers Invoice numbers Case identifiers Boolean values Regions Countries Languages Units Error codes

Normalization must preserve meaning.

Each normalization record can include:

Raw value Canonical value Applied rule Confidence Confirmation requirement

The agent designs sensitive slots carefully.

Potential sensitive categories include:

Identity attributes Payment information Account-recovery information Health information Precise location Government identifiers Banking information Authentication factors Private communications Security-related details

For every sensitive slot, the schema can define:

Business purpose Collection condition Masking Storage Retention Access Transmission Deletion Prohibited use Escalation

Passwords, one-time authentication codes, private keys, access tokens, and recovery phrases must never be defined as collectable support slots.

The skill creates efficient slot-filling strategies.

Preferred order:

Reuse reliable known values Retrieve authorized system values Derive safe values Ask only for missing necessary information Confirm ambiguous or sensitive values Avoid re-asking confirmed information

The agent uses progressive disclosure.

It asks only the next required question rather than presenting a long form before the intent is understood.

Good question: Which order are you asking about? You can provide the order number or the approximate purchase date.

Weak question: Provide all account and order information.

Confirmation is required when a value:

Is sensitive Is ambiguous Triggers a transaction Changes account state Affects payment Selects termination Causes deletion Changes ownership Triggers escalation Was inferred Conflicts with another value

The skill separates:

Intent Detection Identity Verification Authentication Authorization Eligibility Transaction Approval

An intent can be recognized before authentication, while transaction execution may still require authentication and authorization.

Authentication records can define:

Whether authentication is required Applicable method Point in the workflow Unauthenticated assistance Failure path

Authorization records can define:

Action Required role Required ownership Required approval Evidence Escalation

The skill does not invent unsupported authorization logic.

The skill creates routing architecture.

Routing may depend on:

Intent Sub-intent Product Plan Account tier Language Region Severity Safety Security Customer type Transaction value Entitlement Service status Channel Business hours Specialist requirement

Intent alone does not always determine routing.

Every routing rule can include:

Intent Conditions Primary queue Secondary queue Priority Required context Handoff summary Escalation

Internal queue names remain separate from customer intent labels.

Escalation architecture can support:

Frontline-to-specialist escalation Technical escalation Billing escalation Account escalation Fraud escalation Security escalation Privacy escalation Legal escalation Complaint escalation Supervisor escalation Safety escalation Engineering escalation Outage escalation Warranty escalation

Possible escalation triggers include:

Low confidence after disambiguation Required system action unavailable Repeated workflow failure Policy exception Account-takeover concern Material financial impact Sensitive-data concern Safety risk Service incident Specialist interpretation Customer requests a human Unresolved complaint Required evidence unavailable Unsupported product state Workflow not implemented

An escalation package can preserve:

Detected intent Candidate intents Collected slots Verified slots Missing slots Conflicting slots Customer goal Completed actions Workflow result Risk Requested decision Urgency Channel history Evidence

The skill defines outcome-based completion criteria.

An intent is complete when:

The customer's goal is fulfilled A correct explanation is delivered The case is routed with sufficient context The customer accepts an approved alternative The service confirms that the request is unsupported and provides the approved next path

An interaction is not complete merely because all fields are filled.

The conversation-state model can track:

Active intent Secondary intents Collected slots Verified slots Missing slots Conflicting slots Completed actions Pending confirmations Pending escalations Previous channel Customer preferences Language Accessibility needs

Possible conversation states include:

Discovery Disambiguation Authentication Slot Collection Validation Confirmation Execution Verification Escalation Completion Fallback

The skill creates example utterances using varied customer language:

Formal Informal Short Long Misspelled Indirect Emotional Multi-sentence Context-rich Context-poor Voice-style Chat-style Email-style Regional phrasing

It generates:

Positive examples Negative examples Hard negatives Ambiguous examples Multi-intent examples Fallback examples Sensitive-intent examples Unsupported-request examples

Hard negatives help separate confusion pairs.

Example:

Intent: cancel_subscription

Positive: I want to stop my subscription after this billing period.

Hard Negative: I was charged after I thought I canceled.

The hard negative likely belongs to dispute_charge or failed_cancellation.

The skill creates annotation guides.

Each annotation guide can define:

Canonical label Definition Inclusion rules Exclusion rules Parent intent Sub-intents Positive examples Negative examples Hard negatives Confusion pairs Multi-intent handling Entity guidance Edge cases Annotation notes Reviewer requirements

The skill can assess training-data balance across:

Intent frequency Class imbalance Language coverage Channel coverage Customer-type coverage Regional coverage Product coverage Rare intents Sensitive intents Fallback examples Multi-intent examples Negative examples Ambiguous examples

Synthetic examples must not contradict product behavior, policy, or workflow reality.

Taxonomy quality metrics can include:

Intent precision Intent recall F1 score Top-two confusion Fallback rate Unsupported-request rate Disambiguation rate Slot-completion rate Slot-validation failure Slot-reask rate Routing accuracy Escalation accuracy Handoff completeness Multi-intent detection Abandonment Resolution rate Containment rate Customer effort False-sensitive-intent rate Missed-urgent-intent rate

Containment should never be optimized at the expense of correctness, safety, privacy, or customer effort.

The skill can audit an existing taxonomy for:

Duplicate intents Overlapping intents Missing intents Broad intents Overly narrow intents Internal-language labels Missing sub-intents Weak positive examples Missing negative examples Weak confusion boundaries Missing required slots Unnecessary slots Missing conditional logic Inconsistent entities Missing validation Missing fallback categories Missing multi-intent logic Missing routing Missing escalation Missing completion criteria Localization inconsistencies Governance gaps

Every audit finding can include:

Severity Finding Evidence Operational impact Model impact Customer impact Recommended correction Owner Verification

The skill supports lifecycle governance.

Taxonomy statuses can include:

Proposed Draft In Review Approved Active Experimental Deprecated Retired

Every change request can document:

Requested change Reason Affected intents Affected slots Affected workflows Affected analytics Affected training data Affected routing Risk Approval Migration plan Effective date

Review triggers can include:

Product change Workflow change Policy change New channel New language High fallback volume Routing errors New support team New customer type Regulatory change Changed escalation pattern Changed customer language High-volume uncategorized issue Increased model confusion Increased slot abandonment

When an intent is deprecated, the skill can:

Identify its replacement Map historical data Update training data Update analytics Update workflows Update routing Update documentation Communicate the change Preserve version history Test migration

The skill supports multilingual and regional taxonomies.

Localization analysis can cover:

Regional product names Local billing terminology Legal terminology Date formats Address formats Currency Channel availability Politeness conventions Voice-recognition behavior Local synonyms Script Transliteration Sensitive-language handling

A single canonical backend label can be used with localized display names and examples.

The skill supports channel-specific adaptations.

Chat can use:

Buttons Quick replies Structured forms Links Visual confirmation

Voice requires:

Short prompts Identifier confirmation Recognition-error handling Spelling strategies Interruption recovery Silence handling Repeated-digit confirmation Accessible escalation

Email requires:

Multi-intent extraction Long-form context analysis Attachment references Asynchronous clarification Case creation

Ticket forms require:

Conditional fields Progressive disclosure Validation Required-field rationale Save-and-resume behavior

The semantic schema remains consistent across channels.

The skill aligns taxonomy and analytics without collapsing separate reporting dimensions.

It distinguishes:

Conversational intent Operational workflow Routing queue Ticket category Root cause Resolution code Product Severity Channel Customer type Outcome

These dimensions can be linked but should not be represented as one combined label.

Supported operating modes include:

Full Taxonomy Design: Creates the complete intent, entity, slot, fallback, routing, escalation, and governance architecture.

Intent Catalog Builder: Creates detailed records for every intent and sub-intent.

Slot Schema Builder: Creates required, optional, conditional, derived, confirmation, authorization, evidence, system, and sensitive slots.

Taxonomy Audit: Reviews an existing taxonomy for overlap, gaps, weak boundaries, slot problems, and governance weaknesses.

Annotation Guide Builder: Creates precise labeling instructions, examples, hard negatives, and edge cases.

Fallback Architecture: Creates low-confidence, unsupported, missing-context, channel, policy, safety, and security recovery paths.

Multi-Intent Designer: Defines primary, secondary, sequential, parallel, urgent, and dependent intent handling.

Routing and Escalation Architect: Connects intents and context to operational queues, priorities, specialist teams, and handoff requirements.

Multilingual Taxonomy Designer: Creates canonical labels with localized intent definitions, utterances, entities, and slot prompts.

Testing and Governance Package: Creates test sets, quality metrics, change-control rules, migration guidance, and lifecycle ownership.

The core commercial promise is: transform an unstructured customer-support service into a precise, scalable, privacy-aware, omnichannel intent and information architecture that improves understanding, reduces unnecessary questions, enables reliable automation, preserves context, routes cases correctly, and creates measurable governance for conversational AI.