New to Khoros Flow? This is a great place to start learning about the basic flow workflow and features. We’ve broken this course into 10 short videos. Choose the topics that interest you most. Overview of Flow basics Training your bot to be smarter Creating a fallback Flow Extracting user input Routing with events and conditions Visualizing the conversation with Rich UI Textual Selection lists Code actions Reusable handover flow

Context can be applied within Flows using branches.   Branches are extremely useful when you can expect different input from a user. The following example demonstrates this with a question   Would you like to Takeaway or carry out   that expects 2 different answers.   You can create branches by dragging and dropping triggers on top of each other. It will work with intents, but also for events, timers or unknown triggers. Note: Branches can only exists within flows as follow up steps, and cannot be created for the first step. If you want to achieve that, simply add a another flow with the trigger. Read more Branch out a conversation tutorial How to branch your chatbot in 3 steps

The Flow NLP engine allows your chatbot to understand natural language. The two tasks the NLP can perform is Intent recognition and Entity extraction. Intent recognition can be used to map a user utterance to a predefined bot reply. Entity extraction is used to extract specific data from a user utterance. For these tasks to be successful you'll need to add training data. Intent classification The core of well functioning conversational AI is intent classification. Intent classification is the process of understanding what a user means by the text they type. For example, the user utterance   I want to fly from Amsterdam to San Francisco   can be mapped to the intent of booking a flight. Our Natural Language Processing (NLP) takes care of intent classification but in order to function it needs to be trained with examples that need to be provided by the conversational AI developer. Adding a   Text Trigger   lets you train an intent. When you click the Train button you can add examples for this intent.     Adding more examples enables the classifier to make better predictions. Always make sure you add a least ten examples that are diverse in form, but consistent in meaning. When you have a sufficient amount of examples you can click   Save.   This will save your examples and initiate the training process. Note: Best practice is at least 10 examples When you add fewer than 5 examples, only exact matching will be used. Reusing intents A great way to speed up the development process is reusing intents. This also   improves the quality   of intent classification.   Every intent you create automatically becomes part of you intent library. You can drag and drop any existing intent in other flows to give different answers depending on the context. Tip: Never create duplicate intents Make sure you do not create semantically similar intents: if two intents are very similar, the   probability of misclassification   rises. In that case the best practice is to create a more general intent and then ask follow up questions. Reuse example Start by creating an intent to understand greetings (hi, hello, hi there, hey, etc). After training this intent with examples, reuse it by dragging and dropping it from the library. Now, if a user greets, the system will reply   Hi! How can I help you? . Next, if the user greets again. The system knows that he already has greeted, so it can reply with   Hello again Follow up intents The NLP engine works best if you provide clear examples. In some cases you can also train more generic intents. For example, if a users says   the closest   without any context, it doesn't mean much. But if the user asks it after   I'm searching for a place to park my car , then it becomes relevant. The AI engine makes it possible to create and train these intents in context, and then reuse them in other places. So, if you have a flow on finding parking spaces, training the followup intent 'the closest' makes sense. You can then easily reuse this intent in a flow on finding restaurants or toilets. Confusion When designing your flows it's good to think about the different use cases your bot will serve. One of the biggest challenges is keeping your project from offering too many   identical intents   that   will confuse the NLP. This can be best explained with an example. Example Imagine a company providing support for customers having problems with phones and dish washers. Business wise it might mean each product would result in a different answer. A broken phone might be picked up, while a broken dish washer requires a repair man to make an appointment, Naturally we tend to split these repair questions into different flows, introducing a number of intents for repair questions regarding phones and dishwashers. The training data for the intents might look like: Repair phone intent Hi, I have a broken screen on my new phone, can you fix this? My phone is broken, I want it repaired The phone of my wife hampers and it wont start anymore ... Repair dishwasher intent Hi, I have a broken   door   on my new   dishwasher, can you fix this? My   dishwasher   is broken, I want it repaired The   dishwasher   of my wife hampers and it wont start anymore ...   Can you tell the difference? The problem is this will result in   confusing   the NLP because the example sentences are to similar and would make classification unreliable. Merge intents by subject One way to solve this issue is by combining the two intents into a single repair intent: Repair intent Hi, I have a broken   screen   on my new   phone, can you fix this? My   phone   is broken, I want it repaired The   dishwasher   of my wife hampers and it wont start anymore ...   With a single intent you would mark the products as entity types. Next you can use the extracted product within reply actions and conditions to differentiate the follow up flows. Explanation The NLP engine interprets sentences differently than humans. To us   I have an issue with my mother-in-law   has a totally different meaning than   I might have some problem with the television. To the system both sentences are about someone having a problem with a certain object (no pun intended). Since we cannot prevent this from happening, it's best to   create intents   based on   subjects. Read more Working with entities instead of multiple intents Other best practices Balance the number of examples across intents Try not to create multiple intents with just 10 examples and a number of intents with over 100 example sentences. It's better to keep intents balanced with around an equal amount of training examples. The infamous Hello intent When there is an intent with many short examples (often a 'hello' or greeting intent), short user utterances that are unclear are often misclassified as belonging to this 'hello' intent. Often it can be solved by   turning off NLP   for this intent. Limit the number of entry intents More intents results in a lower degree of classification accuracy, because the probability of choosing the wrong intent increases. Consider keeping the number of intents that can be matched at the entry level of a flow to a bare minimum. If your use case requires hundreds of entry intents, try to   merge as many intents   into the the same topic. Keep your intents clean. On the other hand, make sure you don't merge intents that are not semantically similar. Keep your intents clean and clear!  

Creating dynamic flows can be done in multiple ways the easiest one of them is using conditions. With conditions, you can design if / else statements without the need of writing code.   What can conditions be used for? Conditions open up a wide range of possibilities to dynamically branch or redirect flows. Some examples: Show a different response if a handover takes place outside business hours Send a user into an on-boarding flow if a certain piece of data is missing Give a personalised reply whenever a certain tag exists How do Conditions work You can drag and drop conditions below any trigger or reply action. Conditions work fairly similar to branches. Like branches you can add multiple Conditions, re-order or individually remove them. Below any Condition you can add any number of reply actions and follow up triggers.   Matching Conditions are validated in run-time. In other words, each time a Condition is matched, the system will dynamically determine if the Condition is valid or not based on its rules. The order of Conditions is important. If you create multiple branched Conditions for example, A, B, C, the system would first try to match A, next B and finally C. This also means that the first Condition that is valid will be the winner and any other Condition on the same level, even if the rules match, is ignored.   Any Condition can have multiple rules. By default a Condition won’t have any, you’ll need to add them manually. A rule-less Condition is always considered valid. If a Condition has more than 1 rule, you can choose if the Condition should match   all   rules or if meeting   any   rule is sufficient for the Condition to be valid. Rules There are different type of rules you can select. Param Validate params that the NLP engine extracted or were created somewhere along the way. Using this rule you can check if a param exists, contains a certain value or matches a custom entity type. Channel With these type of rules you can match if the conversation is taking place on a certain type or specific channel. Tag Tags can be added and removed throughout the system. With these rules you can validate if a tags exists, has existed or contains a certain value. User Besides tags, you can use this rule to validate certain user profile data like name, language and profile picture. Business hours When you configure business hours you can use this rule to determine if the business is open or closed. AB Testing Choose   AB test   to differentiate a response. Note that AB tests only work in combination with other AB test conditions. The division is random. So when you add 2 AB test conditions, either A or B has a 50% chance to get matched.  

Test your app directly within the Design app using   Try out   in the top menu. You can start having a conversation with your bot and see how it's performing and check if it's collecting the right parameters.   Tip: Reset context while testing Use on reset to clear all parameters and context and clear to start with a clean screen  

Connect, deploy and integrate your Flow project. Built-in integrations Flow can connect directly to different built-in   integrations   like   channels , customer service , analytics    and backend services using   APIs. This allows you to connect a bot to   Messenger   in just a few clicks, place a   web widget   on your website or integrate Flow deeply into your own customer experience software.   Connector When Flow is directly connected to a message channel such as WhatsApp, Flow will provide conversation control. This is important for both measuring a bots performance as it is for hybrid customer service use cases where human agents need to pick up with conversations that are handed over. Agnostic It's also possible to implement Flow behind an agnostic messaging service that controls the conversation.  

  Design and build Conversational apps faster. Flow provides the complete solution for designing Conversational user interfaces. Flow helps you create any type of automation on any type of messaging or voice channel. Build a chatbot Easily start building a chatbot or AI assistant. Design flows by dragging and dropping triggers and reply actions. Make it dynamic Make requests to your backed using code actions and webhook actions. Manage state to customize the experience. Connect We provide a wide range of the most popular messaging apps you can connect your app with. Add integrations Add integrations to connect third-party services like Front for handoff or chat base for bot analytics.

With the help of   Multi-language design   it is possible to set up a single project in multiple languages and regions, without the need for duplicating flows, intents or entities. It provides a workflow that greatly reduces time and complexity for maintaining multi-language projects.  Note:  Use Multi-language design if you create a bot that has the same flows for multiple languages. At any time, additional languages can be added and synchronized based on a primary language. By default, the system will try to machine-translate content when synchronizing changes between languages. How to enable You can enable the feature by adding additional languages. Go to the   Languages   overview inside the   Project settings   screen. Choose   Add new language   and after that choose the   Translate   option.   Note: Multi-language design requires all language to use the "multiple languages" model With Multi-language design, one language will be the primary language. You will only be able to change triggers and flows inside this language. All secondary languages can only be translated. For translation you need to choose a language and a region. This always you to differentiate a language for multiple regions. Workflow After translation has completed, you can review the secondary languages and approve or adjust changes in replies and training examples. High-over the workflow is like this: You make changes to flows inside the primary language, you will see an indication your primary language is out of sync with a secondary language.   Note: You can only make changes inside the primary language. Secondary languages are read-only, except for replies, entities and intent examples. When you've completed your work you can choose any secondary language and synchronize your changes   In the following screenshot you can see pink dots that mean that flows and intents were added and translated, but not approved yet.   Approve all synchronized changes. Once you've approved all changes, you'll see the indication all languages are back in sync     Additional information Machine-translation is applied if possible You can assign channels to specific languages, regions or a combination of the two Depending on the channel, we'll try to detect the language of a user and route the them to the correct language You can only change flows inside the primary language You can add additional training data or tweak replies for secondary languages In edge cases you can use a condition to differentiate a certain flow

The following describes roles and permissions in the   Flow.ai   dashboard:    : Users have access to the feature or functionalities    : Users have no access or visibility of the features or functionalities    : Users have partial access to the feature (such as users might not be able         to delete data)     : Flow customers have access to these features or functionalities

Khoros products offer a number of different integration options so that you can customize the experience to fit your needs. Our integrations typically fall under one of these categories: Data , Reporting , or Automation Framework . Overview of Khoros Flow Integrations Flow Basics: Integration Data Data integrations involve connecting Khoros products to third-party sources (for example, a payment processor) so Khoros can pull information in from or push content out to these sources.  Check out our Overview of Payment Actions for Flow. Reporting Reporting integrations involve third-party services (for example, Google Analytics) that can ingest metrics and other raw data from Khoros products for data reporting and visualization purposes. Chatbase Google Analytics Automation Framework The automation framework enables you to integrate bots with the Khoros platform. This can involve automated messaging services, automated author profile updates, automated post tagging, automated conversation routing, and more. Learn more about Khoros Flow Messaging Capabilities . Sources Coosto Facebook Messenger Freshchat Front Khoros products MessageMedia Slack SMS Sparkcentral Telegram Twilio Web Widget WhatsApp Zendesk Zapier