Multitenancy in Google Dialogflow

Question

My company is currently trying to build a multitenant chatbot using Google Dialogflow. We're exploring the tools at our disposal, but the documentation on the topic is still a bit scarce. Our understanding and definition of multitenancy, in this context, would allow us to have slightly different conversational flows depending on the company the end user works for. For example:

User A from company Foo wants to order an ice cream. Company Foo provides a set of flavors (chocolate, vanilla, mint) and only serves ice cream cones, but lets users add garnishes to their ice cream (chocolate chips, sugar sprinkles).

User B from company Bar wants to order an ice cream. Company Bar provides a set of flavors (strawberry, pistachio, lemon) and serves ice cream cones and cups, but offers no garnishes.

Both users should have the same exact conversation, except that the available lists of flavors and ice-cream containers would depend on the tenant. Furthermore, there should also be the option to extend parts of this conversational flow, such as company A providing the ability to add garnishes. Both conversations should start and end with the same intent (I want an ice-cream/I am ready to pay).

Our secondary goal here would be to minimize the Dialogflow-side redundancy: ideally, there would be only one agent, and ideally, intents that require no duplication should not be duplicated.

Our architecture is not client-driven; the client is always intercepted by our back-end server (C#), which is responsible for handling the interop with Dialogflow. We think this gives us more flexibility and better integration with our existing stack.

We have identified these promising features:

• Sub intents
• Input contexts
• Overrideable entities
• Mega/Sub agents

But we haven't identified a clear path yet. We're also considering the available alternatives, such as Microsoft's BotBuilder, Amazon's AWS Chatbot and the open-source ChatterBot.

In short, is there a best practice when it comes to this? If not, any ideas and thoughts on the matter would be very welcome.

Answer 1

First let me say there are not well established guidelines, the Chatbot world is evolving as we speak.

I personally see 2 approaches:

• platform-based: Chatbot conversation is built on a platform (ie DialogFlow, Chatfuel, etc.. plenty out there) which provides NLP capabilities, a form of conversation designer, metrics maybe and (mostly all platforms) the possibility to add a webhook for integrating your backend
• framework-based: Chatbot is built on low-level framework (ie MS Bot, Rasa) that supports the design/development/execution of a conversation within your code.

In the first case using DialogFlow gives several advantages but you have 2 major limitations: cloud-dependency (all user traffic goes via Google) and there is limited flexibility in the design of your conversation.
If you achieve to maintain one conversation flow then your webhook can populate data on demand (ie different flavors, different options), thats very doable.
Your conversation can also contain branches (add garnish) which you activate via an event (generated from the webhook if company data has a certain flag), this is also doable but it starts making the conversation more cumbersome.

In the second approach you have a lot more flexibility (all conversation flow is in your code) but obviously you need to 'provide' the missing features, for example integration of LUIS for NLU, etc.
Rasa is a good framework if this approach seems interesting to you: it is Python based and it offers built-in NLU capabilities as well as channel integrations.