The immense commercial potential of mobile messaging apps coupled with the interest in robotics and artificial intelligence have recently given a massive push to the development of chatbots’ UX and conversational flows. Powered by machine learning, natural language processing, and live operators, chatbots can provide customer service, answering customers’ questions in real time, empower users to take necessary actions without ever leaving the messenger chat, and much more - hence the huge demand for bot development services. A couple of years ago, creating a high-performing bot was a tedious and complex job. However, chatbot builders have been evolving as well and now are able to offer better services and new benefits to bot makers.
Continuing the series of blog posts on chatbots, we are about to share Onix’ experience in handing over chatbots to the customer. However, since the handover of any project is a topic of great importance and interest on its own, we dedicated the first part of the post to it. Just in case, you are welcome to skip the first part and get to the meat of chatbots specifics in the second.
‘Project handover’ is a common term, but it is important to remember that in fact, it is deliverables, knowledge, and the responsibilities that must be handed over from one team to another (or anyone supposed to keep working on the project in the context of certain duties).
A project handover is not a date, but a process. This post relates to transferring a software product from the developers to the customer, and although it is typically a final phase in software development process, planning for it should start at the very beginning. For example, at the end the stakeholder is expected to agree that the quality specifications of the product have been met. But it will be impossible if the criteria of performance were not clearly defined and documented at the beginning of the project. Be proactive. Make sure that project management plan defines when something should be handed over and what precisely the requirements are.
A common mistake at handover has been compared to ‘a midwifery approach of passing the child on at birth and wishing the parents good luck’: some development teams and even PMs perceive project handover as the end of their job and the start of the job by another team, or the stakeholder, or the end users. What happens if you fail to prepare your successors for their responsibilities in the benefits realisation and risk mitigation after the project transfer? You’ll put at risk the results of long hard work of your team and provoke ‘not getting what was paid for’ reviews! So, try your best to understand your customer's needs and help solve their problems - for your own benefit.
Onix-Systems is an outsourcing company whose customers are located all over the world. This implies some additional difficulties at the stage of project handover. Here are some tips based on first-hand experience:
A closeout and handover procedure is largely dependent on each project’s nature and circumstances. However, both PMs and customers may compile a suitable project handover checklist by selecting items from the following:
Ideally, a project handover should be complete after you receive an email like this: ‘As per our meeting, the handover has been completed to my satisfaction.’ Time to celebrate!
For further details of successful transition of a project from the project team to the end users’ business as usual activities, please check out this APM Research Fund study. And now we proceed to the specifics of handing over chatbots.
The process must be as clear and easy for the customer as possible. The handover of code and hosting setup is pretty similar to that for websites and usually raises few questions. However, the transfer of all resources and accesses to the customer’s accounts may entail long conversations or writing complex instructions. For example, if the customer cannot share their Facebook account password for privacy reasons. In this part, we’ll explain easiest ways to transfer accesses in some popular bot platforms and frameworks.
Bot development involves several outside platforms:
All of the services require a phone number to create an account, and the same number is not always allowed to be associated with multiple accounts. This means the developer has to work from his/her own account. Luckily, some chatbot development services have lately facilitated the management of accesses to bots and applications that are being developed:
Let’s take a look at specific handover details for each one.
Developers can assign the administrator roles to any other Facebook user. When a chatbot is developed, a Facebook application is created alongside a separate page for the same bot. For this reason, it is necessary to hand over the administrator rights for each part:
For Facebook application:
For chatbot’s Facebook page:
Go to developer console; you can see all of your projects (called ‘agents’) on the page https://console.dialogflow.com/api-client/#/agents. Select the agent you are going to hand over (you have to be the owner) and follow these steps:
N.B. Currently, only Reviewer and Developer roles are available, so it is better for the customer to create an empty agent at the project start and then grant access to the developer.
The Export/Import option allows transferring archived data from one account to another.
Export/Import of the app’s settings is one of the ways to transfer settings. You can do it on the page where applications are listed.
Once the customer has an export file, they will be able to recreate the developer’s chatbot instead of creating a new one. When creating a new app, the customer just needs to click on ‘Import App’ instead of ‘New App’.
Distributed access to the application is another, more convenient way. Once on the application page, go to ‘Settings’. At the bottom of the page, you can see the ‘Collaborators’ section. It allows adding other users (by entering their emails) with editing options.
N.B. Unlike Facebook, LUIS does not permit complete transfer of access to new users, so you’d better have the customer create an app in their account and then grant access to the developer.
It is an online service where the developer has to create a separate project for each chatbot. A project may have multiple owners-administrators, which is an advantage: just click on ‘Settings’ on the project page, scroll down to the bottom, and list all of the owners-administrators’ emails.
The service is integrated with the cloud platform Microsoft Azure; the settings are handled in the Azure interface. On the project page, click on ‘Settings’ and enter the new admin’s email at the bottom of the page. Save the changes.
Telegram allows for the easiest handover process. The only requirement for a bot’s interaction with the service is an API token. When you create a bot, you can test it using your own authorization token. When you give the source code to the customer, they can use the bot @BotFather, generate a new token, and apply it with the code.
Every project should have a clear end with a correct handover of the product, useful information and responsibilities. Understanding of the customers or users’ needs and the ability to transfer knowledge to those who ‘overtake’ the project are essential. For example, when you are building chatbots for customers, the necessity to give access to new bot administrators afterwards determines who is to create the project in the appropriate framework at the start.
Use these tips to assure a successful project handover:
Pre-handover preparation, professional management of the process, and post-handover support are the keys to successful transition and eventually the entire project success. If you ignore the best practices, lagging projects will lead to loss of money, reputation, and clients.
We hope you found the tips of project handover useful. If you are interested in chatbot development, we will be happy to hear from you!
(Special thanks to Serhii Kholin, Director of Innovations at Onix, for providing valuable details about chatbot projects handover)