How Amazon’s conversational flow builder helps sellers with plug and play assistance

Sellers day to day work on Amazon marketplace involves using workflows such as registration, listing of products, inventory management, order management, return tracking that need personalized help contents and contacting seller support with prior context. The process is time consuming for sellers to contact support and remain blocked unless the query is answered or resolved and we found a window of opportunity to delight our sellers with better customer experience and save their time by providing instant assistance for each of the workflows. The solution was to add researched help content in a conversational flow with multimedia support to make it intuitive and easy for sellers to understand.

Sometimes seller can have specific queries related to current context such as GST (Goods and service tax) while completing registration flow. The platform will determine and provide specific help contents to seller to help complete the workflow. The trigger of conversational flow will depend on a unique ID that we will discuss later in the article.

Seller navigates through conversational flow and gets queries resolved instantly in most of the cases and can still contact seller support through conversational flow if queries are not resolved. The first thing that will come to mind now is to identify sellers pain point in each workflow and build and launch similar Chat flows in all of them. Building individual assistance has lot of challenges such as

• Build a new frontend for each workflow with specific needs. For example, a listing conversational flow should support list views while personalised content for new seller should support videos.
• Build separate storage system for each flow and not being able to reuse common components such as contact support at end might be common in all conversational flows.
• Integration of storage and front end for each workflow is time consuming effort and launching for all workflow will not be feasible.
• Building components to track key metrics in configurable manner that provides ability to create analytics, personalization and recommendation centrally is more useful compared to each flow building the capability separately.
• Different use case might require different templates such as list of videos, images, etc. and there should be a common platform having templates built which can be re-used.

The platform provides a conversational builder interface which can have rule based contents or can be integrated with services. It will be used to create conversational flows which can assist selling partners in completing workflows on Amazon marketplace sellers website and app. In order to make it easy to use and intuitive, contents will be added in a graphical pattern and will allow builder teams to use multimedia in conversation flow.

The platform involves an internal portal which will have all the tools and resources to build chatbot powered by backend system for storage and processing and a chatbot created using the platform which seller will interact with. Let us dive deep in each of the components.

In order to build a fast, scalable and simple solution we are using a commonly available UI framework called React for content creation front end which will have easy to use tools and features for builder team to build plug and play conversational flows. The portal will provide pre populated templates and preview on the go along with creation which will be powered by our platforms Backend system.

The platform will be used across multiple workflows managed by multiple users and we need to have process in place for smooth onboarding and permission management. We are using a solution along with AWS AppConfig which simplifies the administration of applications at scale by deploying configuration changes from a central location and fetching permissions to provide right access to users. User can onboard on platform with chatbot name and permission resource for group-based authorization which will be stored on AWS app config. The process is designed to handle new use cases such as approval workflow.

The builder interface will provide UI for flow creation which will need a system to map, store and process contents and provide it to sellers when required. In its current form the chatbot allows pre populated selections based on queries most frequently asked by sellers but the design should be extensible to take direct input from sellers.

Challenges in building and modeling the conversational flow

Builder team will have contents which they want sellers to go through however each content should have capability to refine to more specific content allowing sellers to navigate through help contents in an organized and intuitive way. This means we can have huge number of interconnected contents and to store this data in conventional way is not easy and will pose many challenges such as

• Huge number of diverse content such as video, images, text will have interconnected relationships.
• In builder platform we want to display whole graph as a view while building the flow and normal access will make the process slow.
• New contents can be added in between and some existing content might require removal and with already complex relationship between contents this will be heavy operation.
• We also want to reuse contents cross platform so the storage should handle that.

User will have pre populated queries which are clickable and will help them navigate to related content. Each of these queries are mapped to unique queryId which we will discuss in next section and the corresponding response will be returned. The design is extensible and in next update it will be integrated with natural language processing providing options to sellers to write their queries.

In next version the user will have option to provide direct input and we will use AWS Lex which provides the deep functionality and flexibility of natural language understanding (NLU) and automatic speech recognition (ASR). Also as we scale and provide direct input processing we will leverage AWS Kendra which is a highly accurate and intelligent search service that enables users to search data using natural language processing and advanced search algorithms. It returns specific answers to questions with high accuracy.

Let us dive deep on a single content and its relation and this will lead us towards our final structure. A content can have texts or multimedia and we will create a common model generic enough to hold all types of files and multimedia. A node will be collection of all related contents(Text, multimedia, links, etc.) combined together to provide single response on query click. Now Let’s call this q1 which will have option to navigate to other content endpoint called nodes q2, q3 and so on. This is actually a graph where each node is interconnected. An edge e will be reference (queryId) of another node which can be navigated to from current node and will be stored in parent node’s sub query list.

We can break this structure in nodes and edges where each node is a query and its relation to child nodes are actually sub queries.
Once we have decided the mapping we have a simpler problem in hand where we have to model this in database.

• A single content is a node we can have many nodes in our conversational flow we can name them n1, n2 and so on.
• A node will have option to navigate to other nodes and we can call this relation as e1, e2 and so on.

Mapping the content relation in DynamoDB

We will use the above structure and visualise our builder platform view and then go in the details of storage. Each content will have a unique Id let’s call it query Id and it will have links (edges) to other queries say subquery id. DynamoDB is perfect for this use case to fetch values based on keys (query Id) so each entry in DynamoDB is individual query.

We will have Query Id and SubQuery Id along with workflow name to be used in keys and indexes for all contents. This implementation will serve us with all the requirements. We can get specific Query (content) for sellers with query Id and all the associated sub queries.

In the seller dashboard workflows sellers will have option to invoke chatbot by clicking on floating button having redirection to conversational flow which was built using builder interface. The chatbot will have multimedia and help contents to assist the seller as they navigate through it and will also provide an option to contact support team if issue is not resolved. Let us dive deep in the design for this component.

In order to improve performance and minimize latency the static assets and resources including files, CSS, JS etc should be deployed to a content delivery network (CDN). This will replicate the assets over a geographically distributed network of proxy servers and data centers and the files for users download request will be served from a closer location. This will reduce bandwidth cost, latency and increase availability of content globally.

We are using Amazon CloudFront for this which speeds up distribution of static and dynamic web content. CloudFront delivers content through a worldwide network of data centers called edge locations. When a user requests content that is served with CloudFront, the request is routed to the edge location that provides the lowest latency, so that content is delivered with the best possible performance. We can configure cloudFront to return default root object and in our case it will load index file stored in S3 and it will have reference to static assets.

In order to analyse if chatbot is helping sellers and keep on improving the content we will capture granular level activities such as most clicked chat flows, latency and various other metrics. Seller will have option to provide feedback at end along with rating which will be processed to improve experience further. We are using Amazon redshift which uses SQL to analyze structured and semi-structured data across data warehouses, operational databases, and data lakes.

Best practices in building chatbot platform

• The builder platform should have visual representation to provide better customer experience.
• Chatbot is something which evolves and we can keep on adding data sources and processing platforms such as Lex, Kendra or service integrations such as registration or order tracking and the design should be extensible for that.
• The content storage and processing should not be coupled with user facing UI or have direct dependency so that it can be reused with custom client bots.
• Templates should be defined based on common usecases and all the content that can be part of a single response should be mapped together in a node.
• There should always be option to navigate to contact support in case chatbot is not able to resolve query. We can take feedback in such scenarios which should be optional.

The conversational flow is built to help sellers complete the workflows with help contents. The system will be extended to allow sellers complete workflows from Chatbot. For example seller registration using chatbot.