Wizard solution as no-code flow generation system
In today’s digital era, a company’s reputation, success, and growth depend on its ability to properly assist and communicate with its customers. This communication must be prompt and accurate so that customers’ concerns can be handled promptly.
At Agoda, we have a team called the CEG (Customer Experience Group), whose primary responsibility is to assist customers in resolving any issues they may be experiencing. However, to properly assist customers, the CEG team must recall a significant number of processes.
Because of this, we developed an internal tool called the “Agoda Wizard.”- a workflow guidance tool to help our customer service agents work more effectively and efficiently and ultimately help our customers simultaneously.
The Problems We Faced
There are several processes for handling cases. Before now, it was challenging to find the right article in our knowledge base. Agents had to recall as much information as possible to manage customer cases properly. With this procedure, human error was inevitable.
In the past, if a reservation’s price needed to be altered, the agents were required to know the computing technique, manually calculate the new price, and input it into the database. This is also susceptible to error.
To solve these challenges, we developed the Agoda Wizard. This greatly reduces human error risk and also helps agents handle cases faster.
What is Agoda Wizard
Agoda Wizard is a no-code tool to help non-technical people build workflows and automate manual calculations and API calls.
Agoda Wizard System Architecture
For Agoda Wizard to be successful, it should be easy enough to be used by a non-technical person. It should also have a built-in experimentation capability to enable SOP experimentation and the ability to measure the effectiveness and efficiency gained from the SOP changes.
Another criterion is the Agoda Wizard also needs to be scalable. It should be able to load the page in a browser in a few seconds. It should also be able to handle hundreds to thousands of concurrent users with a small resource. This constraint made us take a different approach to executing the flow.
Agoda Wizard comprises three main components:
- Agoda Wizard Designer UI,
- Agoda Wizard API,
- Agoda Wizard UI.
Agoda Wizard Designer UI and Agoda Wizard UI are developed using Reactjs for their main UI library. While Agoda Wizard API is written in Scala programming language.
Agoda Wizard Designer UI
Agoda Wizard Designer UI (Designer) is the web application where the designer creates, design, manage, and deploy their flow. The designer has a flow admin page where the users can see a list of available flows. It also has the transition editor where the user can design the transition of the flow, connecting one node to other nodes.
There is also the node editor where the user can define the node’s UI or non-UI components. The node editor includes the preview engine to render the UI component on the fly while the user adds or removes the UI components.
API or the integration point designer helps the users to create and define the integration point. The integration point allows the flow to do an API call by providing the necessary parameters for the API.
Agoda Wizard API (AWAPI)
AWAPI is an integral part of the system. It is the backend system that provides several endpoints that allow designer applications to load, save, and deploy the flows and integration points. It connects the Agoda Wizard System with the other APIs and Agoda’s internal services.
Agoda Wizard UI
Agoda Wizard UI is the main web application where the users load and execute the flows. It contains the flow engine that executes the flow and the rendering engine that renders the UI components to the web browser.
One thing that makes our Agoda Wizard solution scalable and fast is that the flow execution engine is implemented on the client side, which means all the flow states and logic are executed on the client side, in the browser. There are very few API calls needed to execute a flow.
Flow Execution Engine
The flow execution engine in the Agoda Wizard UI understands how to execute a flow. It starts with initializing the variables that come from the parameters in the URL. The minimum parameter needed to launch a flow is the flowIdwhich tells the application to load the corresponding flow from the backend. The engine will parse the flow and all node definitions to find if the flow contains any integration point and load the integration point definition from the backend. Once all the necessary data is retrieved, it will start by reading the starting page and executing the integration or API, if any.
If the node contains a UI component, the engine will stop the execution and render all UI components within the page until the user wants to continue to the next page by pressing the “Next” button. If there is no next page, the flow will end, but if there is still a next page or a subflow found, the engine will load the subflow definition to the same as when it loads the main flow.
How does the Agoda Wizard do the magic?
Flows
At the very heart of Agoda Wizard lies the flow. A flow is a step-by-step instruction a user will follow to achieve a specific goal. A combination of transitions and nodes defines a flow. A flow can always be executed as independent or part of another flow (see subflow).
Transitions
The transitions define the possible paths of pages that a user can take during the flow execution. A transition object represents a particular node/page and contains the possible output keys and the corresponding page of that output which will be the next node. A flow can start from any page defined as the starting page within the flow and ends with any page that does not have any output/result. As shown in the example below, `Cancel booking success page` and `Cancel booking failed page` are the terminal pages. A transition is represented as a simple JSON object as follows:
The same transition then can be translated into a flow chart as below:
Nodes (Pages)
The node defines the page’s UI (User Interface) and Non-UI components that a user sees and interacts with and contains the logic that decides the user’s transition path. In the Agoda Wizard Designer, a node is represented in Agoda Wizard DSL (Domain Specific Language) syntax, written in YML format to make it readable. Then in the database, we save it as a JSON object.
UI Components
UI components are the components that will be rendered to the page. UI components can be grouped into two, informational and input components. Informational components can display information to the users, such as paragraphs, lists, tables, titles, buttons, and highlighted texts. Input components can gather user input, such as input boxes, checkboxes, date pickers, dropdown selections, and radio buttons.
There is a toVariable field in the input box component example. It tells the Wizard to save the user’s input into “yourAnswer” variable inside the flow. Then it can be consumed by the logic section of the node component.
Non-UI Components
Non-UI components are the components that are not rendered in the UI. We call our non-UI component an integration point component. It can do an API call to Agoda Wizard API, and from there, it calls our other internal APIs and get the response, and puts it into a variable inside the flow.
Node logic
Node logic defines the transition logic from one node to another. It can be simple logic to return a string value or more complex logic to do complex calculations, looping, conditional code block, etc. Besides a standard Javascript library, we also provide custom functions allowing users to interact with Agoda Wizard’s internal variables. The user can also carry out some common date time manipulation, send messages, track some variables, or check which environment the flow is currently running.
Variables
During a user journey inside a flow, the node will populate data from external API calls or user’s inputs on the page. It will store them into global variables on the web application. Once created, variables are available for usage in the entire flow session. In the node definition, we can store/create a variable using the toVariablefield or consume the variable using the fromVariable field. Storing and accessing a standardized syntax is important for future usages, such as creating an index for all available variables in a page or a flow.
Subflow
All flows can be used as a subflow of another flow. A subflow is a concept where a particular flow is used as part of another flow. The importance of subflow is about reusability and keeping a flow design simpler. All variables produced by a subflow will be available and used by the main flow and all other subflows where the subflow is used.
For example, there are two flows. The first flow populateBookingInfois a very simple flow to call the endpoint to populate all booking information and map all variables. The second flow simpleBookingCancel is a simple booking cancellation flow. Both are independent flows and can be executed independently. The cancellation flow will use populateBookingInfo flow to populate the booking information and use the variables in the rest of the flow.
The same transition can be translated into a flow chart as below.
To wrap this section, here is an example of a simple flow stored in our database as a JSON object. It defines the name of the starting page in the startPage field and has a transitions field that contains the transition objects and a nodes field that encompasses all definitions of node objects. We store the flow definition as a single object so it will be easy for retrieval and do not need any join query in the database.
How Agoda Wizard solved our problems
Onboarding new customer service agents
In the past, onboarding a new CS agent took more than a month before they could handle a case alone. Wizard speeds up this process.
Changing and updating SOP
Before Agoda Wizard, Changing and updating SOP meant, even for the smallest changes, we had to re-train all of our CS agents by issuing memos of the changes and ensuring 70% adherence. With Agoda Wizard, all CS agents will automatically follow the new updates by updating the flow. We can easily measure the impact and effectiveness of the new SOP.
Experimenting with SOP
Before Agoda Wizard, experimentation with SOP was impossible since everything relied on the CS agents’ manual actions and processes. With Agoda Wizard, there are no more manual actions and processes. The CS agents follow and execute the instructions in the flow.
Consider the following simple flow example, we can easily include our CS agents in our experiment by allocating them to the A or B side. Depending on the allocation result, they will be directed to different paths within the flow. From here, we will be able to measure how much efficiency we will gain if we move to the new SOP.
Fast flow development
Since Agoda Wizard is a “no-code” platform, it will only take a few minutes to set up a simple flow. If the flow needs data from new APIs or services, we can add it in a matter of hours for service integration and sanity testing, compared to using a custom software development process, which might take days. People who understand the business needs can easily make changes without help from software engineers using this fast-flow development process.
Challenges
Having a no-code development platform comes with its challenges. Here are some of the things that we found and some of the features that we developed to overcome the challenges:
- Flow versioning and deployment; Usually a flow will be actively developed and updated daily. To avoid pushing half-developed flow, we developed a concept of draft, version and live version so changes made during the development will not impact real users in production.
- Flow testing and debugging; In the early days of Agoda Wizard, it was very hard for us to debug. As a result, we developed Flow Debugger, a feature that is available during flow development and helps to find if there is any problem with the flow faster.
- Production monitoring and debugging; If there is a production issue, we have created a comprehensive monitoring and alerting system to spot these issues.
Conclusion
We have explained why and how we built Agoda Wizard and how it has helped our customer service agents to work more effectively and efficiently.
Some areas we did not cover in this article are flow deployment and flow debugger. Another area is the Integration Point Designer, which helps integrate new endpoints or APIs much faster. We will take a deep dive into these topics in our future articles.
Acknowledgements
Special thanks to Rinlapat L. for your contribution to this article.
