Hero - Build your bot

Teneo's model for understanding language provides us with multiple ways to recognize an intent using [Match](/studio/flows/concepts/triggers) in triggers.

![3 matches](//images.ctfassets.net/2vbtnveccz5s/1YLiXdkSyoSaIixSRlVf0Z/0992bc12e23a9d337c837aed37835827/3_matches.png?classes=w60)

!!! More information on Match can be found [here](/studio/flows/concepts/triggers#match-requirements)

## Class Match

Classes use machine learning to determine what an input is about. You train a class by providing training phrases (called 'learning examples' in Teneo) in the [Class Manager](/getting-started/class-manager) that are as close to real user inputs as possible. You can either create your own Class or let Teneo generate one for you as seen [here](/getting-started/your-first-flow#populate-the-trigger). We recommend starting with 10-20 example inputs per class.

## TLML Syntax Match

Teneo Linguistic Modeling Language (TLML) Syntax Matches use a [language condition](/studio/language-understanding/concepts/language-conditions) to understand what users are saying. The TLML Syntax Match is expressed using Teneo's [condition syntax](/studio/reference/condition-syntax). TLML Syntax Matches look at words used, their order, synonyms, and other linguistic properties to understand what an input is about. A language condition to cover inputs like 'I would like to order an espresso' could look like this, for example:

```tlml
%HOW_DO_I_BUY.PHR & %COFFEE.NN.SYN
```

You can either hand-craft a language condition yourself, or let Teneo automatically [create it for you](/article/build/flows/how-to/use-conditional-match-requirements#generate-a-condition) from a set of examples, after which you can edit the condition.

## Language Object or Entity Match

Just like the TLML Syntax Match, the Language Object and [Entity](/article/build/flows/concepts/entities) Match use a single [Language Object](/studio/language-understanding/concepts/language-objects) as conditions.  
An example of each can be found here:

*   [Language Object](/studio/conversations/how-to/create-a-custom-order-group#create-a-new-flow-and-add-a-match-requirement-for-a-language-object)
*   [Entity](/getting-started/build-a-slot-filling-flow#configure-the-transition)

## Which Match should I use?

The possibility to combine all of the Match Requirements provides us with the power of machine learning and the precision of condition syntax, but it can be difficult to determine which trigger to use for which purpose. The following are suggestions that can help us make the best of the intent.

!!! Note that Match Requirements can be used in both Triggers and Transitions.

![chat1](//images.ctfassets.net/2vbtnveccz5s/2uaczqtit5NKayOchPiCry/f2b4c0baf78516eb20bf8f43989827c1/chat1.png?classes=w60)

### Classes only

The class matches are the 'go-to' use for Triggers when creating a flow. When the class is performing as intended, the flow is triggered correctly.  
If you find that the class is a bit too greedy, i.e. triggering on too many inputs, you can require a higher *confidence* by adding a context restriction __Class Confidence Medium__ or __Class Confidence High__. This is demonstrated in the page on how to [combine match requirements](/studio/language-understanding/how-to/combine-match-requirements).

!!! A flow can have multiple class triggers. This allows us to attach [listeners](/studio/conversations/concepts/listeners) to each trigger and apply different confidence levels.

### Classes and TLML Syntax

When the Class match is performing well, but we also have a language condition that we trust more (specifically using Entities or rich synonyms), we may choose to add both a class and a corresponding match requirement to our flow. In this case, it could be one [Entity](/article/build/flows/concepts/entities) that might be valuable to cover, or an advanced set of words using a [Condition](/studio/language-understanding/concepts/language-conditions) in addition to adding training examples to your class.

The trigger, in this case, should be stored in an order group above the order group containing the trigger with the Class Match Requirement. This way, the Conditional Match Requirement trigger will be evaluated first. If an input happens to not be caught by the Condition created by the user trigger, the trigger with the Class Match Requirement might catch it. Having both a trigger with a Conditional Match Requirement and a trigger with a Class Match Requirement also has the advantage of allowing us to easily improve the performance of the flow by adding more training data to the trigger (without updating the language condition of the other trigger).

If necessary, we can increase the *confidence* of the class by applying the pre-defined [context restrictions](/studio/conversations/concepts/context#predefined-context-restrictions) 'Class Confidence Medium' or 'Class Confidence High'. We can do this if the class trigger turns out to be too greedy.

!!! More information on creating a new context restriction can be found [here](/studio/scripting/how-to/define-a-scripted-context).

### TLML Syntax only

You can choose to not use a class at all for certain intents. This is a good approach when the classes created is not performing well enough, it is stealing inputs, or it is confusing the solution model, for example. A language condition is much more reliable in such cases. Examples are [follow-up](/getting-started/deal-with-follow-ups) triggers, or triggers that should trigger when inputs consist of just a [particular keyword](/studio/conversations/how-to/create-a-custom-order-group#create-a-new-flow-and-add-a-match-requirement-for-a-language-object) (or synonyms thereof).

If the language condition of the Match is very precise, matching on very specific inputs, we will most likely want to add it to an [order group](/studio/conversations/how-to/create-a-custom-order-group#adjust-the-group-ordering) above the other triggers' groups. This will prevent a less precise trigger from accidentally catching the input from this trigger, which is more precise.

If the trigger is fairly broad, on the other hand, and we want other triggers to be evaluated first, we can add it to an order group below the precise trigger's group. This will prevent the broad language condition from inadvertently catching input that could have been caught by a more precise trigger. More information on ordering can be found [here](/studio/conversations/concepts/ordering).

!!! Note that TLML Syntax Match triggers cannot be improved using the [Optimization](/article/optimize/refine-your-bot/how-to/improve-your-class-triggers) panel, or by just adding example inputs to the trigger. To change the behavior of a trigger with a TLML Syntax Match, you need to modify its [language condition](/studio/language-understanding/concepts/language-objects).

### Combining Matches
This in essence is a combination of the Matches available to an intent trigger. The trigger uses a Class Match on top of having a Condition/Entity/Language Object Match, plus some TLML Syntax constraint. We use this when the trigger is performing OK but we specifically need to constrain the current class with some conditional part.

For example, a trigger 'I love you' includes a Class Match 'I_LOVE_YOU' with 20 training examples. Adding a Condition allows us to force the intent containing the word 'you' and not trigger when using a negation like 'I **don't** love you' using the following condition on top of the Class Match:

```tlml
%YOU.REC & !%NEGATION.REC
```

!!! Combining Matches is also supported in transitions.

Since these triggers make use of an intent trained by a class, we can still improve this class using the [Optimization Panel](/article/optimize#optimize-classes).


Build - Match Requirements

Teneo's model for understanding language provides us with multiple ways to recognize an intent using [Match](/studio/flows/concepts/triggers) in triggers.

![match-9](//images.ctfassets.net/2vbtnveccz5s/3r6jBcaq2irpLoZdhHGJJu/f503c6623361c7d99345211627719949/match-9.png?classes=w60)

!!! More information on Match can be found [here](/studio/flows/concepts/triggers#match-requirements)

## Class Match

Classes use machine learning to determine what an input is about. You train a class by providing training phrases (called 'learning examples' in Teneo) in the [Class Manager](/getting-started/class-manager) that are as close to real user inputs as possible. You can either create your own Class or let Teneo generate one for you as seen [here](/getting-started/your-first-flow#populate-the-trigger). We recommend starting with 10-20 example inputs per class.

## TLML Syntax Match

Teneo Linguistic Modeling Language (TLML) Syntax Matches use a [language condition](/studio/language-understanding/concepts/language-conditions) to understand what users are saying. The TLML Syntax Match is expressed using Teneo's [condition syntax](/studio/reference/condition-syntax). TLML Syntax Matches look at words used, their order, synonyms, and other linguistic properties to understand what an input is about. A language condition to cover inputs like 'I would like to order an espresso' could look like this, for example:

```tlml
%HOW_DO_I_BUY.PHR & %COFFEE.NN.SYN
```

You can either hand-craft a language condition yourself, or let Teneo automatically [create it for you](/article/build/flows/how-to/use-conditional-match-requirements#generate-a-condition) from a set of examples, after which you can edit the condition.

## Language Object or Entity Match

Just like the TLML Syntax Match, the Language Object and [Entity](/article/build/flows/concepts/entities) Match use a single [Language Object](/studio/language-understanding/concepts/language-objects) as conditions.  
An example of each can be found here:

*   [Language Object](/studio/conversations/how-to/create-a-custom-order-group#create-a-new-flow-and-add-a-match-requirement-for-a-language-object)
*   [Entity](/getting-started/build-a-slot-filling-flow#configure-the-transition)

## Which Match should I use?

The possibility to combine all of the Match Requirements provides us with the power of machine learning and the precision of condition syntax, but it can be difficult to determine which trigger to use for which purpose. The following are suggestions that can help us make the best of the intent.

!!! Note that Match Requirements can be used in both Triggers and Transitions.

![chat1](//images.ctfassets.net/2vbtnveccz5s/2uaczqtit5NKayOchPiCry/f2b4c0baf78516eb20bf8f43989827c1/chat1.png?classes=w60)

### Classes only

The class matches are the 'go-to' use for Triggers when creating a flow. When the class is performing as intended, the flow is triggered correctly.  
If you find that the class is a bit too greedy, i.e. triggering on too many inputs, you can require a higher *confidence* by adding a context restriction __Class Confidence Medium__ or __Class Confidence High__. This is demonstrated in the page on how to [combine match requirements](/studio/language-understanding/how-to/combine-match-requirements).

!!! A flow can have multiple class triggers. This allows us to attach [listeners](/studio/conversations/concepts/listeners) to each trigger and apply different confidence levels.

### Classes and TLML Syntax

When the Class match is performing well, but we also have a language condition that we trust more (specifically using Entities or rich synonyms), we may choose to add both a class and a corresponding match requirement to our flow. In this case, it could be one [Entity](/article/build/flows/concepts/entities) that might be valuable to cover, or an advanced set of words using a [Condition](/studio/language-understanding/concepts/language-conditions) in addition to adding training examples to your class.

The trigger, in this case, should be stored in an order group above the order group containing the trigger with the Class Match Requirement. This way, the Conditional Match Requirement trigger will be evaluated first. If an input happens to not be caught by the Condition created by the user trigger, the trigger with the Class Match Requirement might catch it. Having both a trigger with a Conditional Match Requirement and a trigger with a Class Match Requirement also has the advantage of allowing us to easily improve the performance of the flow by adding more training data to the trigger (without updating the language condition of the other trigger).

If necessary, we can increase the *confidence* of the class by applying the pre-defined [context restrictions](/studio/conversations/concepts/context#predefined-context-restrictions) 'Class Confidence Medium' or 'Class Confidence High'. We can do this if the class trigger turns out to be too greedy.

!!! More information on creating a new context restriction can be found [here](/studio/scripting/how-to/define-a-scripted-context).

### TLML Syntax only

You can choose to not use a class at all for certain intents. This is a good approach when the classes created is not performing well enough, it is stealing inputs, or it is confusing the solution model, for example. A language condition is much more reliable in such cases. Examples are [follow-up](/getting-started/deal-with-follow-ups) triggers, or triggers that should trigger when inputs consist of just a [particular keyword](/studio/conversations/how-to/create-a-custom-order-group#create-a-new-flow-and-add-a-match-requirement-for-a-language-object) (or synonyms thereof).

If the language condition of the Match is very precise, matching on very specific inputs, we will most likely want to add it to an [order group](/studio/conversations/how-to/create-a-custom-order-group#adjust-the-group-ordering) above the other triggers' groups. This will prevent a less precise trigger from accidentally catching the input from this trigger, which is more precise.

If the trigger is fairly broad, on the other hand, and we want other triggers to be evaluated first, we can add it to an order group below the precise trigger's group. This will prevent the broad language condition from inadvertently catching input that could have been caught by a more precise trigger. More information on ordering can be found [here](/studio/conversations/concepts/ordering).

!!! Note that TLML Syntax Match triggers cannot be improved using the [Optimization](/article/optimize/refine-your-bot/how-to/improve-your-class-triggers) panel, or by just adding example inputs to the trigger. To change the behavior of a trigger with a TLML Syntax Match, you need to modify its [language condition](/studio/language-understanding/concepts/language-objects).

### Combining Matches
This in essence is a combination of the Matches available to an intent trigger. The trigger uses a Class Match on top of having a Condition/Entity/Language Object Match, plus some TLML Syntax constraint. We use this when the trigger is performing OK but we specifically need to constrain the current class with some conditional part.

For example, a trigger 'I love you' includes a Class Match 'I_LOVE_YOU' with 20 training examples. Adding a Condition allows us to force the intent containing the word 'you' and not trigger when using a negation like 'I **don't** love you' using the following condition on top of the Class Match:

```tlml
%YOU.REC & !%NEGATION.REC
```

!!! Combining Matches is also supported in transitions.

Since these triggers make use of an intent trained by a class, we can still improve this class using the [Optimization Panel](/article/optimize#optimize-classes).


Studio Web - Build - Match Requirements

Match Requirements

Analyze your bot

Analyze Log Data

Analyzing sessions

Augmenters

Concepts

Extract values with Augmenters

How To

Metadata

Running custom queries

Counting coffees with Metadata

Reference

Teneo Query Language Cookbook

Teneo Query Language Reference Guide

Teneo Query Language Syntax Overview

Teneo Query Language

Data hierarchy

Event

Property

Session

Transaction

How to

Explore session statistics

Find stuck flows

Generate session logs

Locate and view a session

Make use of skip constraints

Make use of sub queries

Query variables

Troubleshoot the Safetynet

Use relative dates in queries

Query Syntax

Command

Constraint

Meta-parameter

Selection

Transformer

Build your bot

Bot design

Best practices

Data footprint

Encrypting user data in sessions

Flow checklist

Plan your bot

Starting a new Teneo project

Writing good answers

Writing good examples

Conversations

Context restrictions

Flow stack

Greeting message

Listeners

Ordering

Safetynet

Create a custom order group

Handle ambiguous inputs

Make your bot pro-active

Share information between flows

Use listeners

Flows

Bulk Import

Entities

Junctions

Outputs

Sub-Flows

Transitions

Intent triggers

Variables

Add a script to your flow

Branch at the beginning of a flow

Use TLML Syntax Match

Use a Sub-Flow

Use Bulk Import

Language Understanding

Annotations

Attached scripts

Language conditions

Language objects

Languages

Lexical resources

Libraries

Localization

Match requirements

Used words

Combine Match requirements

Create a solution in your language

Create your own language objects

Find language objects and entities

Localize a bot

Normalize the user's spelling

Optimize language conditions

Recognize plural and singular

Store what the user said

Advanced Condition Coding

Annotations Reference

Condition Syntax Reference

DateTime Handler Reference

DateTime Handler

Engine Scripting API Reference

Input Processing Path

Language Object Reference

Prebuilt Entities

Scripting

Engine scripting API

Groovy basics

Integration manager

Resource file manager

Scripts

Add a Groovy class

Add an integration

Add files to your solution

Annotate user inputs

Anonymize user data

Define a scripted context

Populate output parameters

Store input parameters

Test your bot

Run automated tests

Test your bot with Botium

Dialog Tester

Deploy your bot

Engine API

Versioning and Publishing

Publish your bot

Version Flags

Work with Version Flags

SDK's

Android

JavaScript

Node.js

Getting started

After Match

Extract Entities

Class Manager

Introduction to transitions

Introduction to entities

Deal with Follow-ups

Dialogue and Context Model

Getting started with Teneo

Handle interruptions

Skip conditions

Teneo in 10 minutes

Flows and match requirements

Entities and After Match

Your First Flow

Your First Solution

Optimize your bot

Optimize classes

Improve the balance

Review Inputs

Refine your bot

Debug your bot in Tryout

Use data to improve your bot

Use Teneo's improvement tips

Troubleshooting

My flow doesn't trigger

My flow behaves unexpectedly

I see warnings in Tryout

Suggestions

root

Table of Contents