# Intent And Search These settings work together to determine how Aisera interprets and responds to user messages. Form Intercept controls ticket deflection at the form level. Intent classification thresholds control how confidently Aisera must match an intent before acting on it. Knowledge base serving settings control which articles are returned and how. Exception handling settings control what Aisera does when no match is found at all. ## Form intercept Form Intercept is a ticket deflection feature. When a user submits a form, such as a support ticket, Aisera checks whether an existing knowledge base article already answers the user's issue and offers it before the form submits. The configuration below controls how long Aisera waits for that check to complete. ### Form Intercept max Wait time (ms) for model response | **Type** | Text field (integers) | | ----------- | --------------------- | | **Default** | `3000` | Sets the maximum time, in milliseconds, that Aisera waits for a response from the intent classification model before deciding whether to intercept a form submission with a knowledge base article. When a user submits a form, Aisera checks whether an existing knowledge base article already answers the user's issue and offers it before the form submits. If the model responds within this window, Aisera can present a self-service answer. If the model does not respond in time, the form submits normally without any intervention. The default is `3000` milliseconds, or three seconds. Increase this value if Form Intercept deflection is not occurring as expected in your environment. Decrease it if you want form submissions to proceed faster when deflection is a lower priority. This setting only applies when **Form Intercept** is active for the bot. ## Intent classification ### IntentClassifier Casual Threshold | **Type** | Text field (decimals) | | ----------- | --------------------- | | **Default** | `0.9` | Sets the minimum confidence score required for a casual intent to be recognized. Scores range from 0 to 1. When the intent classifier identifies a user message as casual, it assigns a confidence score. If that score meets or exceeds this threshold, Aisera treats the message as casual and responds accordingly. If the score falls below the threshold, the casual classification is discarded and Aisera processes the message through standard intent matching instead. Raise this value to reduce false casual classifications when task-oriented messages are being incorrectly treated as casual conversation. Lower it to allow more messages to be treated as casual. In form intercept mode, casual intents are always excluded regardless of this threshold. See also: [IntentClassifier Action Threshold](#intentclassifier-action-threshold), [IntentClassifier Action Dialog Threshold](#intentclassifier-action-dialog-threshold) ### IntentClassifier Action Threshold | **Type** | Text field (decimals) | | ----------- | --------------------- | | **Default** | `0.8` | Sets the minimum confidence score required for a non-casual intent to trigger a direct fulfillment response. Scores range from 0 to 1. Intents that meet or exceed this threshold are fulfilled directly. If exactly one intent meets the threshold, Aisera fulfills it. If multiple intents meet the threshold with the same score, Aisera presents a disambiguation prompt. Intents that fall below this threshold are not directly fulfilled and are handled by the lower-confidence dialog path instead. Raise this value when users are receiving fulfillments for intents that do not match their actual request. Lower it when Aisera is frequently failing to act on requests it should recognize. Adjust carefully, too high a value causes Aisera to over-prompt for clarification, while too low a value causes incorrect fulfillments. In form intercept mode, this threshold is overridden by the form intercept channel configuration and this setting has no effect. See also: [IntentClassifier Casual Threshold](#intentclassifier-casual-threshold), [IntentClassifier Action Dialog Threshold](#intentclassifier-action-dialog-threshold) ### IntentClassifier Action Dialog Threshold | **Type** | Text field (decimals) | | ----------- | --------------------- | | **Default** | `0.6` | Sets the minimum confidence score below which a non-casual intent is discarded entirely. Scores range from 0 to 1. Intents that fall below this threshold are dropped before any fulfillment logic runs. Intents that clear this threshold but fall below the IntentClassifier Action Threshold enter a lower-confidence handling path: if two or more such intents exist, Aisera presents a disambiguation prompt asking the user to choose. Intents that clear both thresholds are fulfilled directly. Lower this value when Aisera is too frequently returning no response to requests it should at least attempt to handle. Raise it when users are receiving irrelevant disambiguation prompts driven by weak intent matches. See also: IntentClassifier Casual Threshold, IntentClassifier Action Threshold ## Knowledge base serving ### Present Answer Card For Single BOL | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | When enabled, if the model identifies exactly one high-confidence BOL-matched knowledge base article and no intent-matched articles, Aisera presents only that article as the answer, suppressing all other search results. Disable this if you find that users are not seeing the full range of potentially relevant articles in their responses. ### Disable Search if there is any Intent/BOL KB | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | When enabled, if the model identifies knowledge base articles through intent or BOL matching, Aisera retrieves only those specific articles and does not run a broader search. When disabled, Aisera runs a broader search regardless of whether intent or BOL matches exist. If no intent or BOL matches are found, a search always runs regardless of this setting. ### Use Title First in TicketIQ RelatedKbs instead of description | **Type** | Checkbox | | ----------- | -------- | | **Default** | Disabled | Controls which field Aisera uses as the primary search query when looking up related knowledge base articles for a ticket in TicketIQ. By default, the ticket description is used first, with the title as a fallback if the description does not return results above the score threshold. When enabled, the title is used first and the description becomes the fallback. Enable this when ticket descriptions in your environment are too long, inconsistent, or low-quality to produce reliable search results, and titles are more concise and representative of the issue. This setting only applies when the **TicketIQ Policy** is disabled. When the policy is enabled, it controls query input directly and this setting has no effect. ### Ontology Filters | | | | ----------- | ------------------------ | | **Type** | Text field (JSON array) | | **Default** | All entity types enabled | Controls which named entity types are eligible to match when Aisera performs ontology-based searches against your knowledge content. Only content tagged with at least one of the selected entity types is eligible to surface through ontology-based matching. The available entity types span general language categories such as `PERSON`, `ORG`, `GPE`, `LOC`, `DATE`, `TIME`, and `MONEY`, as well as domain-specific types including `ITSM`, `HRSM`, `PHONE_NUMBER`, and `EMAIL_ADDRESS`. By default, all 23 entity types are active. Narrow this list when your deployment should only surface knowledge content relevant to specific entity domains. For example, an IT service management deployment might restrict to ITSM-relevant types to avoid surfacing results matched on unrelated entities. Removing all entity types from this list disables ontology-based matching entirely. This field accepts a JSON array of entity type strings: {% code overflow="wrap" %} ```json ["PERSON", "NORP", "FAC", "ORG", "GPE", "LOC", "PRODUCT", "EVENT", "WORK_OF_ART", "LAW", "LANGUAGE", "DATE", "TIME", "PERCENT", "MONEY", "QUANTITY", "ORDINAL", "CARDINAL", "ITSM", "HRSM", "PHONE_NUMBER", "EMAIL_ADDRESS", "UNRECOGNIZED"] ``` {% endcode %} ### Exception handling ### Enable Search in Exception Handling | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | Controls whether Aisera performs a knowledge base search as a fallback when no intent matches a user's message. When enabled, Aisera searches the knowledge base during exception handling to attempt to surface relevant content. When disabled, the knowledge base search step is skipped and exception handling continues to other fallbacks. Disable this if knowledge base search results in exception handling are producing poor or irrelevant responses and you want to remove it from the fallback sequence without disabling other exception handling behavior. See also: [Enable Entity Driven Conversation in Exception Handling](#enable-entity-driven-conversation-in-exception-handling), [Enable Global Skill in Exception Handling](#enable-global-skill-in-exception-handling) ### Enable Entity Driven Conversation in Exception Handling | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | Controls whether Aisera uses entities detected in a user's message to find matching content when no intent is matched. When enabled, Aisera uses any knowledge graph entities identified in the query to look up associated knowledge base articles and skills during exception handling. When disabled, the entity lookup is skipped and exception handling falls back to keyword search and skill matching instead. Disable this if entity-driven results in exception handling are surfacing irrelevant content and you want to rely on keyword search and skill matching as the fallback instead. See also: [Enable Search in Exception Handling](#enable-search-in-exception-handling), [Enable Global Skill in Exception Handling](#enable-global-skill-in-exception-handling) ### Enable Global Skill in Exception Handling | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | When no intent matches a user's message, Aisera checks whether the query matches a skill that exists in the platform but has not been added to the current bot. When enabled and such a match is found, Aisera acknowledges the user's request and notifies them that the skill is not yet available, prompting them to contact an administrator. When disabled, this check is skipped and Aisera proceeds to a standard no-answer response. Keep this enabled when you want users and administrators to be made aware of skill gaps in the current bot. Disable it if you prefer users receive a standard no-answer response instead. The notification message is customizable via the `exception_intent_handling_non_added_skill` message in Conversation Messages. See [Conversation Messages →](https://docs.aisera.com/aiseragpt/how-to-set-up-an-aiseragpt-bot/add-conversation-messages#to-edit-conversation-messages) for instructions on editing this message. See also: [Enable Search in Exception Handling](#enable-search-in-exception-handling), [Enable Entity Driven Conversation in Exception Handling](#enable-entity-driven-conversation-in-exception-handling) ### Enable auto escalate when not understood | **Type** | Checkbox | | ----------- | -------- | | **Default** | Enabled | When enabled, Aisera automatically escalates a conversation to a live agent after failing to understand a user's message a set number of consecutive times. When disabled, Aisera does not escalate based on unrecognized messages and users must initiate escalation manually or through another configured path. Enable this when you want to ensure users experiencing persistent understanding failures are connected to a live agent without having to ask. This reduces frustration in conversations where Aisera repeatedly cannot match an intent. This setting requires the After how many Not Understood attempts threshold to be configured and a live agent channel to be set up for the bot. If no live agent channel is configured, enabling this setting has no effect. See also: [After how many Not Understood attempts](#after-how-many-not-understood-attempts) ### After how many Not Understood attempts | **Type** | Text field (integers) | | ------------ | ----------------------------------------------------------------------------------------------------- | | **Default** | `2` | | **Requires** | [Enable auto escalate when not understood](#enable-auto-escalate-when-not-understood) must be enabled | Sets the number of consecutive unrecognized messages required before Aisera automatically escalates to a live agent. Each time Aisera fails to understand a user's message, it increments a counter that persists for the duration of the conversation. When the counter reaches this value, Aisera sends an escalation message and presents live agent options. With the default of `2`, escalation triggers on the second unrecognized message. Lower this value to escalate users more quickly when they encounter repeated failures. Raise it to give Aisera more attempts before handing off, which is useful if your users frequently send ambiguous messages that may not match on the first try. The escalation message is customizable via the `not_understood_escalation_message` message in Conversation Messages. The default is: "I am having trouble following you, let me offer you escalation options." See [Conversation Messages →](https://docs.aisera.com/aiseragpt/how-to-set-up-an-aiseragpt-bot/add-conversation-messages#to-edit-conversation-messages) for instructions on editing this message. See also: [Enable auto escalate when not understood](#enable-auto-escalate-when-not-understood)