Since the dawn of time (almost), people have been communicating via conversations. And this worked great for many thousands of years. Then computers happened, and suddenly we all had to learn a different mechanism for communicating. This was loosely referred to as computer-speak. And over the years it changed as technologies changed. From mainframe, to MS-DOS, Windows/Mac, client-server, and then the web. But the one constant over the years was that it was still computer-speak. Meaning that it had nothing to do with how humans actually spoke to each other.

And this is the crux as to why your Enterprise systems are so difficult for your organization to use today. And why it costs you so much money to support everyone, and everything.

Implementing a chatbot solution for your Enterprise, if done right, will save your organization millions of dollars per year, increase organizational efficiency, and improve user satisfaction with your systems.

The ROI is dramatic. A conversation with a chatbot should cost less than 50 cents per conversation. Whereas a conversation with a human is costing your organization at least 10+ times as much, and, if HR professionals are involved, often 100+ times as much.

But to get there everyone needs to be comfortable with what this new era will look like, and how to get it started. To that end, the recommendation of Gartner (and we wholeheartedly agree) is to pilot the solution to ensure that you don’t embark on a failed IT journey.

So, here’s our recommended 10 steps to ensure that you hit this one out of the park on the first pitch.

Step 1: Understand how much it will cost

First off, pilots should be cheap, and they should be short (and if they are not, then that’s a red flag). But it’s also super-important to understand what the cost structure looks like once you’ve rolled this out across your entire organization. So, work with the vendor that’s pitching the pilot to fully explain what things will cost after the pilot is done and you’ve decided to roll this out to everyone in your organization.

The last thing you want to tell your CEO is that the pilot was a success, but it’s not cost-effective to roll out the solution organization-wide. Remember, the #1 reason for implementing a chatbot solution is to reduce operational costs.

Step 2: Understand how much of your team’s time will be needed, and what is required to support it

All implementations will require some time from your internal teams. That’s normal and desirable. But you really should avoid solutions that could tie up teams of your people for months on end.

Also, once implemented, you should expect support and maintenance to be minimal too. If you suddenly discover you are now performing “dual maintenance” of content, then this means you chose the wrong solution.

A chatbot solution should require minimal involvement from your team to setup, monitor, and support.

Step 3: Ensure that infrastructure/security is discussed and vetted early on

It feels like every day we hear about a security breach at some of the biggest internet companies in the world. Concerns about security and infrastructure are very real and must be addressed. It’s critical to understand the architecture that the chatbot provider is proposing, as you may discover that your data is not only flowing through channels you’d prefer it not to, but is also actually being stored in places it shouldn’t be.

At IntraSee we take infrastructure and security very seriously. Which is why we reside solely within the fully certified Oracle Cloud.

Step 4: Identify your pilot audience

We would recommend around 200 people for an average chatbot pilot. And while it may be tempting to select them all from the IT department, we would recommend a broad range of your organization, but would focus on employees/managers or students/faculty (in the higher education world).

Try to select a broad demographic that most accurately represents your organization.  Including those who speak any languages you would want the chatbot to support.

Step 5: Understand any language requirements

Chatbots are capable of conversing in many languages, some better than others. So be aware of which languages the people in your organization will be conversing in, and check with your vendor to get feedback on how competent they believe the chatbot is in those languages.

Adjustments can be made for any languages that the chatbot may not be completely proficient in. Just let your vendor know up front.

Step 6: Have a pilot-to-production plan in place

Ok, so the pilot went great. Everyone loved it and now you want everyone in your organization to get to use it. Be sure that you have a pilot-to-production plan in place before you started your pilot. Because now you’ll know what to do next, and how much it should cost.

The key to pilot-to-production is that it should be a relatively quick process. We would say that four weeks should be attainable, but that anything more than twelve weeks would be excessive.

Step 7: Think in “conversational” terms when solving for use-cases: what do people need help with?

Talk to your help desk team, and your HR Generalists, they can provide you with the top 100 things that they get asked on a frequent basis. That’s a great start. But also get insight into how the conversations go.

• How are the questions phrased?
• Are there follow up questions based on specific answers?
• Are discovery questions needed?
• Would the inclusion of specific data help with the conversation?
• What’s the best way to answer a question?
• Does the answer vary based on location, seniority, etc.
• Is a follow up required after the answer has been given?

This will help with configuring how the chatbot interacts with your people.

The idea is that the chatbot understands your best practices and follows them every single time. Just like a perfect employee would.

Step 8: Understanding context

It’s critical that your chatbot understands context, because then it can make helpful suggestions during a conversation. Just like a well-trained support person would. Plus, it’s also important that the chatbot understands who you are and where you are. This way a meaningful conversation can take place, as opposed to a simple Q&A.

So, for example, if someone asks a question about taking time off work, the chatbot should already know that if the person resides in Germany, that it should respond with whatever is the German policy (because that may be different to the American policy). And, also, that it offers to help the person complete a leave of absence request, if they so wish.

Step 9: Think big, but be agile

There is a school of thought that says that chatbot pilots should only include a small number of “intents” (aka functionality). We at IntraSee do not subscribe to that point of view. A pilot using this methodology may appear to be a success – but that could all be an illusion.

The main (but not only) purpose of a pilot should be to see what would happen in a full rollout to your entire user population, but with a smaller group of people where you can monitor and see what works and what doesn’t. And the only way to do that properly is to try and make your pilot scope close to what you expect your full production scope to be.

This means you also need to be agile during the pilot and can adjust to things you see, such that by the end of the pilot you have a close match to what your pilot-to-production path would be. HINT: This is why you need a configurable and fully automated solution.

Step 10: Don’t try and “roll your own” chatbot pilot

There’s no doubt that chatbots are the most exciting thing to happen in the software industry in the past 20 years. And there’s a ton of examples on the internet about how easy it is to create a chatbot that can accept pizza orders. But Enterprise chatbots are highly complex and sophisticated creatures. And to build one properly from scratch would take many years. So, the strong recommendation would be to use something already built off-the-shelf that can quickly be configured for all your needs. This isn’t just our recommendation, this is the recommendation of Gartner too, from last year’s Gartner Application Summit.

Gartner’s clear advice for IT is to stop building things that are already built. Ultimately, it’s not just a waste of time and money, it also contributes to IT being primarily focused on being in “maintenance mode”, instead of “innovation mode”.

If you’d like to know more, fill out the following form and we will send you our white paper.