So I know I have discussed this before lightly here, but I would like to focus more on the nuts and bolts of an internal search feature in the bot. I thought it could be accomplished by adding a keyword section to each gambit and a short description area (able to be toggled on and off) for us to add that will display to the end user. Then we can add keywords to each gambit and offer a simple search feature off of that. To take it further would be to add a search button that is built into the TARS display for users to select regardless of where they are in the bot. A search feature is typically what other bot techs out their seem to focus on as their primary use-case (I think that is silly personally because there is a search function on our websites, and with API integration we could replicate that in TARS while still having all the other original features other bot techs do not offer), but for large bot builds, an internal search could drastically speed up users getting to the information they need within mega bots. I have noticed trends with users that will back up through multiple conversation flows because they are not quite sure where they need to go. In the beginning I supplemented this by adjusting wording and options, but you can only do so much without affecting your users that CAN find what they are looking for.
With our current bot system BEN, we could use this, but I wouldn’t add keywords to ever gambit, because some areas I don’t want users to jump to out of the conversation flow. Being able to strategically identify which gambits can be jumped too by the user will make the search useful without becoming troublesome. The real question is how to jump to those gambits without interrupting the process by reloading a bot from a startgid, or internally in a bot deployed as a widget or embedded. What do you think about that challenge @vinit?