With the rise of bots, software designed to automate tasks (making a reservation, purchasing a product, distributing content, providing customer service or sending coupons), there is a degree of development knowledge needed to create intelligent, robust and scalable bots. By nature, bots are applications that live on top of existing communication channels that take advantage of their interface UI and adds AI (Natural Language Processing) to facilitate communication between the software and an individual.

Bot development differs from app development is many ways. Apps require proper planning, a specific designer for UX flow and platform specific building blocks. Bots on the other hand offer a more streamlined and linear execution. However, building a bot isn’t as simple as it looks. Let’s take a look at how bot development is done today and a new emerging development method.

Building a Bot from Scratch Today

Bots rely on several preparation steps to ensure a good working bot. You need to prepare the conversational script as part of your bot spec, the bot architecture and your development environment.

Spec & Conversational Script

The conversational script acts as use case of actual user conversation. Because most bots interact with users via a chat interface, the bot must guide the user toward the answer or task. The content of the script creates a context that relies on user behavior and add-on NLU (Natural Language Understanding).

System Environment & Configuration

Next you need to create the architecture and engineering design of the bot. You need to create both the back-end and front-end ranging from setting up the servers to the front-end conversational interface, user action and any computation needed. A developer will typically need to spin up their own servers, build, deploy and manually wire up the corresponding SDKs, incorporate NLU (Natural Language Understanding), fiddle with platform specific API, manage hosting and preparation of deployment package including processing of dependencies, test and deploy. These steps usually takes developers a bit to set up since there are many connecting interfaces, services, plugins and configurations. Will you manually host it yourself, use Amazon AWS (which requires configurations) or another service? Will you create a management interface to monitor your resource spent and key-value storage of your conversation history?

Bot Development

With your system configuration all set, you can now start building your bot. Use your conversational script to create a working bot while testing it to make sure it responds well and to check for any errors. This step is very straightforward as your spec guidelines gives you the skeleton of the bot.

Deployment

Once you are satisfied with your bot, it is time to deploy it to your hosted environment. You need a stable hosting environment where the bot will reside that allows you enough flexibility to expand your hosting and monitor your bot/resource usage.

Publish to Messaging Channels

To get people to use your bot, you need to distribute it. Publishing your bot to various messaging platform such as Facebook Messenger or Viber gives people a chance to discover and interact with it. Platforms such as Facebook Messenger have a bot store where people can try out different bots. If you have a specific Facebook Page for your bot, you will need to integrate a token key.

The one key drawback when building your own bot is that you will need to set up a hosting environment for the same bot for a different messaging platform. For example, your first bot gets published to Facebook Messenger, you have to re-create the environment AND bot so you can add it to another channel such as Slack or Viber. Each bot lives in its own hosting environment and it is your job as the developer to monitor and manage each environment, conversations, figure out integrations and storing conversational data and so forth.

Ideally, you have built tracking and conversation monitoring into each of the bots. In order to improve the response of these bots, you have to take a look at how users interact with it. By examining potential scripts, you can add them into your bot via an update to the publishing channel.

The Entire Process Looks Like This:

Bot Spec & Script -> System Configuration and Hosting Environment -> Bot Development (coding the bot) -> Testing -> Deployment -> Publishing -> Monitor & Analyze -> Update

Now while the step process looks simple, there are hidden struggles within. Jake Bennett, CTO at Seattle-based agency POP, tried creating a serverless app using AWS Lambda. So even if you don’t host your own application, it isn’t as easy as it seems. He details his struggles in a Venture Beat article, What I learned Building Serverless Apps.

His main challenges was the time spent prior to building the application. It was the time spent configuring, creating and setting up the Lambda functions:

Configuration takes significant amount of time

To develop an app, Jake had to configure the environment for uploading the code, configuring the Lambda function, creating the API endpoint, setting up the IAM security role for the function, configuring the behavior of the HTTP request, configuring the behavior of the HTTP response, creating the staging endpoint, and deploying the API.

This time should be factored in when estimating the project completion time since Lambda functions are nano-services (same if you use other services such as Azure) .

Documentation is sparse so researching is needed

The biggest challenge for Jake was figuring out how to solve problems popping up as the lack of documentation made for wasted time spent researching issues. “Error messages are often cryptic and the number of configuration options is large, making diagnosis time-consuming. Making matters worse, documentation and community support is still immature, so there isn’t a huge corpus of community knowledge to draw from.”

How to balance between tight cohesion and loose coupling in structuring the app

Before the adoption of serverless architecture, functions were thought to exist in a larger cohesive application with shared memory and a call stack. However, there is a lacks of architecture design patterns for serverless applications. “With AWS Lambda, you are literally deploying a single function, outside the context of a larger application. So how do you live without the things we take for granted every day like shared functions and common configuration settings?”

Will you impose every function as a Lambda and create tons of configuration thus affecting performance (since every function invocation will be out-of-process call) or deploy a single Lambda function that acts as a controller for the entire application (you have to oversee the controller function in order to keep it efficient and manageable). Depending on your application, you may need a mix of the two but time spent on architecture can be costly and long.

So if we go back to the process map, even with serverless hosting, you can see how it could take a developer some time to build the bot from end-to-end.

Bot Spec & Script -> Lamdba and API gateway configuration, Hosting Architecture -> Bot Development (coding the bot) -> Testing -> Deployment -> Publishing -> Monitor & Analyze -> Update

Where Bot-as-a-Service comes into the value chain

As the advent popularity of bots, bot platforms are starting to spring up to make development workflow streamlined and simple. There are many kind of bot platform ranging from development tools, infrastructure setup, development frameworks to deployment and publishing platforms. What all these services and products offer is to take the pain from the setup, configuration, building and deployment steps so any user can publish a bot into a messaging platform as soon as possible.

Why a Bot Platform Saves Time

The innovator’s dilemma is searching for new approaches to past problems. How can we optimize the current approach in order to shorten the time and gap so distribution of knowledge and resources can better reach the intended audience? The platform approach takes the optimization level and redefines it into solving the same problem by a new solution (it’s a paradox in itself). A bot platform enables creation of more bot inventory (in the market) without using and wasting more resources (time, manpower, computer processes). The logical thinking is that if we empower and permit developers to build faster and more efficiently; more quality bots will be available on the market and thus letting more people use better bots (increasing developer interest and starting the cycle over).

Our platform, Recime is an end-to-end bot development platform. We encompass a generalized platform that anyone can use to build their custom bot solution and deploy it across various channels. We are the founding blocks to build your fundamental processes such as the bot building framework, the serverless infrastructure, the building and testing environment and deployment method.

Using our platform Jake Bennett would be able to skip the pain points of configuring and setting up his infrastructure and system architecture while cutting down on the deployment time with our custom CLI.