HomeHanding over Projects with Chatbots: From Generalities to the Specifics
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 Alternative-spaces’ 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.
Critical factors of a successful project handover to the customer
‘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.
Alternative-spaces 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:
- Whenever possible, get face-to-face with the customer’s team.
- Don’t urge the customer to read technical documents before they have seen the system – it is inefficient.
- Start the handover with a full system demo. Prepare a short overview of the product functions (the business case, which should have been created long ago, is a good basis for this). Outline the key business processes and ask the customer whether everything is clear.
- It’s good to prepare a FAQ in advance. If you can’t answer a question, have it written down and task a responsible team member with preparing an answer. Don’t be fast to celebrate if you get no questions after the product presentation: the customers may be overwhelmed by the amount of information and not know what to ask.
- In terms of the documentation, the stakeholder may request as much of it as you have. It would be a mistake to give it. Provide only meaningful and useful documentation. Make sure it is all up to date, and tell the customer expressly where to start, if it is not clear.
- Encourage the customer to have several people on their side to read the documents, each in their line, to arrange structured reviews and talks, and to ask questions where they don’t understand something. Having structured reviews will focus the team’s minds and make it rather an interactive task than an ordeal.
- Provide the customer with responsible team members’ email addresses and phone numbers so they can help out in case of emergency.
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:
- Project description is easily accessible
- Project roadmap and past progress are documented
- High level diagrams are explained
- List of tools and access to them
- List of what has been delivered
- Development process description, i.e. how new features are implemented, tested, released and supported
- List of currently involved people, their roles and contacts
- List of previously involved people, and whether it is OK to contact them
- All communication channels are documented
- List of all requests for changes
- List of past major issues with customers/partners and how they were resolved
- Expected problems (scalability, security, etc.) are documented
- Technology stack is documented in a single place
- For code handover, detailed diagrams are created
- New team member has been able to compile, run, test, deploy code to all involved systems
- Code walkthrough is done
- New member has written and deployed code to QA without supervision (e.g., a bugfix or a small feature)
- New members know how and where to find information about the reasons certain design or implementation decisions were made
- Code review time is scheduled weekly
- For system handover, full required access (root, etc.) is provided
- Environments are documented
- Software Licenses are documented
- Backups were tested at least once
- All scripts and tools can be found from documentation or version control
- Process flow diagrams for most common cases are available
- Monitoring is documented
- Support and Maintenance plans include clear steps in the event of a disaster
- List of past issues in searchable format
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.
How to transfer a new chatbot to the customer
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:
- Facebook to create an application or page for the chatbot;
- NLP (natural-language processing) services for text messages processing (for example: Dialogflow, Wit.ai, LUIS, etc.);
- Microsoft, which provides the Bot Framework for easier integration with many 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:
- Facebook for Developers – a platform where applications and chatbots for social network are created.
- Dialogflow (formerly Api.ai, Speaktoit) – NLP/NLU tool with machine learning services developed by Google. It empowers bot makers to build natural and rich conversational experiences and connect with users via Google Assistant, Amazon Alexa, Facebook Messenger, and other popular platforms and devices.
- LUIS (Language Understanding Intelligent Service) – NLP tool designed for analysis and understanding of textual information from users via pre-existing intents (user’s goals).
- Microsoft Bot Framework – open-source, serverless bot builder. It acts as middleware between the application which realizes the logic and users’ chat transcripts.
- Skype for Developers – service designed for developing bots to interact with customers on Skype directly using chat, voice or video.
- Telegram Bot Father – a bot that helps create and set up Telegram bots.
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:
- Go to https://developers.facebook.com/apps/ and select your chatbot application;
- Select ‘Roles’ tab and add a customer as an administrator of the application.
For chatbot’s Facebook page:
- Go to chatbot’s page and select ‘Settings’;
- Select ‘Page Roles’ tab and add a customer as an Admin of this 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:
- Click on ‘Settings’;
- Proceed to the ‘Share’ tab;
- Add customer’s email associated with a Google account in the ‘Invite new people’ section and select the role;
- Save the changes.
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.
Wrapping up
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:
- Plan the transfer of information and responsibility to the right people at the right time
- Produce useful documents for the new team and end users
- Establish a common data environment
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!
READ MORE ABOUT CHATBOTS:
Content created by our partner, Onix-systems.