Tutorials
Last updated
Last updated
In the beginning there were only Chatbots or only Humans in the support scenario. Suddenly the scenario changed and chatbots demonstrated their limits. To have an always fully satisfied customer the new option was to move the AI (chatbot) to humans as soon as it becomes clear that the chatbot is in trouble.
The upcoming conversation design is even more complex, with chatbots specialized for specific tasks, sometimes very short-live tasks, that best address user's needs (or NLP questions). This implies the need for the actors to pass their hand very often during the conversation. Both humans and chatbots go in and out of the conversation with the end user, exchanging the task of conversing with him to solve his problem. So it happens that, for example, a chatbot invites another and that the latter offers an option (a button, an intent or an automated action) to "go back" to talk to the previous chatbot. In the exactly the same manner it happens for humans where the first level operator switch the conversation to the technical staff who discusses with the client and moves back the conversation to the initial operator.
The actual idea is that the conversation's actors (chatbots and humans) should handoff to each others many times during a conversation to address the end-user task in the best possible way. Chatbot-to-chatbots, humans-to-humans, chatbots-to-humans and humans-to-chatbots.
Moreover consider that sometimes the conversation can add other unsuspected actors, like an entire application that appears in the conversation.
This new scenario provides a new challenge: simplify the "orchestration" between all those actors in a way that is as more easy and transparent as possible.
The conversation not only should be perceived by the end-user as seamlessy flowing between all the actors. The conversation should also seamlessly and easily flow for the conversation designer. The one who "design" the conversation flow must have simple "directives" or "APIs" to move the conversation through all the involved actors, when needed.
Here come the Tiledesk Orchestration APIs, designed on top of Tiledesk conversational platform APIs. Sometimes we call Tiledesk as "The conversational application develompment platform", and there is a good reason for this.
