Skip to Content

 

Engineering a rationale

Taking part in organizing the SAP Inside Track (SIT) is a lot of fun, and the effort you put in is definitely worth it in terms of knowledge sharing, networking and experience. To make it work, there are surprisingly many loose ends to tie and things to remember. To help out with this years SIT Silicon Valley (SITsv), we decided to create a Twitter bot that would be able to answer some of the questions that participants might have in the period leading up to the event. There were three main reasons why we chose to do this:

  1. We realized that a lot of the questions we got from attendees or presenter were repetitive. They would make inquiries about the venue, who the speakers were, transportation and so on.
  2. Twitter was chosen as the front and because it is the social medium most heavily used by the SAP community members on the go.
  3. I had to prepare my presentation about Dialogflow.com (previously known as api.ai) and the SAP Cloud platform – so this was great practice 🙂

Mostly we wanted to have fun with technology!

 

Bots are stupid and annoying

When creating the bot or agent, we would like to avoid some of the most common pitfalls. And there are quite a few of them that would make the bot seem stupid and just annoying to interact with. We used some guiding principles, trying to steer clear of those things that make users tear their hair out and cry for some real-human interaction to help them out:

  1. The bot should be simple. Serving a single purpose. If you try to create a bot that will take on the world – and you are not Google, Apple og Amazon – you should really keep it simple. Our bot would answer questions about SITsv 2017. That’s it.
  2. We wanted the bot to be able to learn. If one user didn’t get a good reply, the bot should be able to train with previous errors as input and become better at it’s job. Hence – we wanted machine learning. Perfect fit with Dialogflow.com.
  3. The agent should understand context – not just a decision tree of words – we wanted natural language capabilities. Again, Dialogflow.com does this.
  4. The bot would make it clear that it was a bot, not a human. We named it “SITsv2017 Bot”. It should be obvious that this is a machine, not a person. If we had named it “SITsv Information”, users would not know – and get totally wrong expectations. Loss of trust is common in the world of bots. We therefore made it clear that the bot wasn’t fool proof and still in training.
  5. We also thought about connection to existing information systems to reduce inconsistency and duplicate maintenance. As our existing information system for this event is the SAP Community Wiki – and the amount of information very manageable – we didn’t waste time trying to set up any clever integration. Copy paste.

Building the agent

So, we got cracking. I will not go through the basics of the Dialogflow.com agent setup in this blog – for that I will kindly refer you to my previous entry: Chat with your SAP system using SCP and Google’s api.ai 

We created the following intents:

  • Content
    • This was the main intent, it would brag about the agenda. However, with twitters limited space – we chose to link to the wiki page so that people could get a more in-depth impression.

    Location

    • Address, how to enter the building, registration and so on
  • Time
    • Giving precise date and time for the event.
  •  Transport
    • How to get there – both tips on driving and public transportation
  • Parking
    • Kind of self-explanatory
  • Food
    • Information about our breakfast and lunch
  • Drinks
    • Announcing the most important event of the day: the Happy Hour
  • Price
    • It’s a free event, but not sure everybody knows.

This would be enough to get the bot started in a beta-fashion. More intents would be discovered after “go-live”.

 

The Twitter part

Then we created a Twitter-bot (called App in Twitter) and named it SITsv2017 Bot . We found a nice non-copyrighted logo.

Next step was to hook it up to the agent created on Dialogflow.com. It’s not hard, just follow the template instruction given in the integration section of the agent.

[https://console.api.ai/api-client – 2017-09-21]

 

When this is completed, your Twitter bot is operational. We pinned an tweet to the account disclaiming that this is a bot under training.

 

Taking it for a spin

Next thing to do is to test it out, and get some beta-testers. The great SAP Community and the SAP Mentors helped out, and as you can see sometimes it worked out quite well:

 

 

Other times, not so much:

 

Feedback and improvement – and jokes on SAP CP

Based on the failures we detected over some days, we added new data to the training sets of the existing intents of the agent. A few new intents were also added, some of them needed – others just for the fun of it. As an example, some people asked the bot to tell a joke. In order to do this in a educational manner, we created a HTTP destination on a SAP Cloud Platform NEO trial account, fetching random jokes from the legendary “Chuck Norris Internet Database”. The nerdy section.

We programmed a Java webhook application and started it on SAP CP. The webhook URL was given to the Dialogflow.com bot, and the webhook enabled for the “joke” intent. Voila!

 

Pretty funny, right?

Well. I doubt creating this bot consumed less of our time than answering the questions that the bot actually answered, but it was a great experience. The business potential in this setup is really interesting if you think about switching our 100 people event to a big cooperation, the event location to stores, the agenda to product information and the jokes – no – keep the jokes.

 

What do you think?

 

 

Until next time,

/simen

 


 

Twitter: https://twitter.com/simenhuuse

LinkedIn: https://www.linkedin.com/in/simenhuuse/

 

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply