Following our first Bot blog on 23rd March which marked the start of our ‘Ami’ Bot chatbot journey, we find ourselves deep in talks off the back of discovery and as we explore what the technology can offer. We are also asking ourselves some crunch questions about what precisely we want out of the Bot for the business. This will continue, but views are starting to form.
Ami has thrown up a number of questions and challenges from our lead technical and architecture stakeholders in the Bot project’s team. As a tech firm, some might regard it as an automatic shoe-in for us just to add the Bot simply as an additional cloud option for customers and visitors using our web portal. However, it has to be right for the business, whatever the technology and right for purpose – and certainly before any costs are incurred.
A key question that arose in recent discussions centred on our technology. We needed to check what the structure map was around our infrastructure and ITSM toolsets. Our Service Desk toolset doesn’t come with a baked in chatbot which would have made things simpler, but it was an important exercise as a reminder and a review point for our chatbot options, which led to some positive API additions. Our lead Technical Design Authority, Julian Green has taken time to investigate different Bot frameworks and potential options for consideration. Being a largely Microsoft house, Amicus ITS has ready access to the Microsoft Bot framework. However, whilst the set up would be very fast, that would still require substantial input as it developed. Julian has also investigated the option for us of using IBM Watson as the backbone for the Bot. Both of these options would require substantial input from our technical team and that is where the conundrum lies, as that route could tie up valuable resource. We’ve also engaged with some market leading suppliers with off the shelf options. These might be a more effective route for Ami as a Sales bot for us.
Either way, it has to be technically right to introduce into our portfolio of toolset service options and it has to feel right, so it’s a benefit not a hindrance for anyone to have a conversation with Ami. We know we need a Sales bot at this stage, as a Service bot is a step too far that we are not ready for, but it remains the goal on the distant horizon.
So in terms of where we are today, I think we are on the verge of agreeing the right route on how to make Ami (metaphorically), which hopefully the Board can agree on in June. Then the project team can start to build on the content for the FAQs to respond to sales enquiries. Plus, we have some general housekeeping to review. We need to interrogate the existing routes, including email addresses etc., through which organisations engage with us – as it looks like there are some we no longer use. If we tidy things up, we may see our Reception and Business Services resource time being used more efficiently in the first place, enabling greater focus on the right enquiries. Using technology to work smarter. Sounds good. Above all, we want Ami when she joins us to become popular and user friendly, helping direct people usefully AND managing user expectations too.
Ami is causing us to re-evaluate what we do and how. We will have taken a meaningful step if we can serve our customers more intelligently and flexibly – not only using joined up technology, but also joined up thinking behind the scenes from Board to floor. Change can be hard for any business. Our plans for a soft GoLive in July with Ami Sales bot were perhaps a bit too ambitious on reflection given our gap in knowledge and working implementation. But I have no doubt that following our numerous discussions, research and conversations with experts, that we are heading in the right direction. We just have to get over Ami’s toddler stage and commit to holding her by the hand.