How effective are Chatbots to your business?

How effective are Chatbots to your business?

You know them, you’ve probably seen them on multiple company websites you stumble upon, the chatbot. “Hi there, can I help?”. Chatbots have become the new way to interact with your customers and they provide many benefits. This blog will particularly look at some of the benefits associated with having chatbots for your business and also address some potential drawbacks from their use that are good to consider.

Research conducted for the Harvard Business Review (2018) indicated that firms achieved the greatest performance levels when both human and machine were working together; machine intelligence and human emotion. The first benefit is communication with consumers; chatbots are generally available 24/7 to answer queries and converse with customers. In a modern world of anywhere, anytime communications, consumers expect to have on-demand interactions with organisations. Chatbots allow this to be done, cost effectively around the clock. Whilst not yet a complete replacement for humans, chatbots allow more limited interactions to be handled automatically.

“Consumers want to talk to brands, hence enabling chatbot feasibility can be extremely useful for building brand relationships”

Another potential benefit associated with chatbot technology is that they can open doors into global markets by being accessible and learning multiple languages. The chatbot permits this sort of interaction; consumers wants to talk to brands, hence enabling chatbot feasibility can be extremely useful for building brand relationships.

Furthermore, if one considers the most recent technological advances that have taken place, the transformation of AI and machine learning has taken the business world by storm. Consumers now seek smarter, more agile and receptive interactions from businesses; having a chatbot as part of your online offering can not only encourage your customers to interact with your brand, but also aids in boosting brand image. Having advancing technologies incorporated demonstrates that your business has unique prowess and intelligence and wants to provide a better service to your customers, keeping up to date with technological trends.

Utilising chatbot technology is also very useful for monitoring consumer data and gaining insights into consumer activity and satisfaction. In addition to checking how many people are viewing your brand online you can notice what encourages them to interact, what sort of questions they are asking or what they wish to know more about. Since chatbot interactions ultimately result in captured textual data (rather than audio recording of human telephone calls), there are opportunities to perform automatic analysis more easily identifying patterns including types of queries as well as customer sentiment.  This could act as an indicator to how your business can improve and better serve your customers.

“Having advancing technologies incorporated demonstrates that your business has unique prowess and intelligence”

However, there are some potential drawbacks that must be considered. The most apparent problem is that chatbots require intelligent programming in order to be able to sufficiently answer and respond to questions. Moreover, chatbots can open doors to international markets, so it must have a level of linguistic ability to be effective, and eventually you will need staff who understand that language to handle interactions which go beyond the chatbots capability. Interacting with consumers puts a great deal of trust within chatbots, if the system is slow, unresponsive, or does not provide appropriate answers then consumers will only build a negative opinion, which could tarnish your brand reputation. However, being upfront with customers to let them know they are speaking with a chatbot, not a human, can help lower the expectations of a customer and help the interaction.

According to Forbes (2018) chatbots are the most significant and useful tool that a business can adopt, improving customer service and indicating toward marketing insights that help businesses grow and develop.

Therefore, it is imperative, as is the same with any sort of technology, to build a quality chatbot which is thoroughly tested, especially when it comes to serving your customers and making your business run more efficiently. Poorly designed and configured chatbots will only hinder your process, create unneeded issues and probably some angry customers. Thus, in order to ensure effectiveness of chatbots, creating positive brand equity, relationships and grow your business then the right developer will be key to success, having clear objectives and a commitment to technologically innovative advancement.

Further reading:

 

Why projects fail.  Part I

Why projects fail. Part I

Paul McAteer, Head of Project Delivery, Pulsion Technology

If you have spent any length of time within the IT Industry, you could probably point to a project that you know of that has failed. Some have done so more spectacularly than others, with the occasional few unfortunately making it to the wider media, just to add insult to injury.

So, what is the extent of the problem? The Standish Group’s 2015 Chaos report illustrates a project success rate of only 29% in 2015. Standish Group has been reporting on the software development industry since 1994 and 2015’s figures for success are only 1% up on the year before.

Why is there such a large rate of failure in software development projects? Regardless of whether this is an internal business project or has more of an external focus, what are the common mistakes that seem to be made again and again? This 3-part blog series will consider some of the reasons why projects fail and what you can do to mitigate against failure in the future. Part I looks at requirements gathering.

Clear requirements gathering

The earliest and most important stage of a project is the requirements gathering stage. Regardless of whether you are managing a project on an Agile basis or Waterfall, understanding the scope of the project is key to its success. It’s very unlikely for a traveller to set off on a journey without knowing where they are going, how they are getting there and what time they need to arrive. Same theory in general, applies to a project.

Trouble can start if the stakeholders have difficulty agreeing on the aims and objectives of the project internally. Clarifying that all key stakeholders know and agree on what they need and want, (and have documented and shared this internally) makes for a positive project kick-off!

Making assumptions, as we know can often lead to misunderstanding, frustration and unintended consequences. So, when it comes to the stakeholders communicating their requirements, this needs to be done in such a way that the project team fully understands and is able to accurately restate the requirements as an acknowledgement of their understanding.

Are the requirements separated into functional and non-functional? It’s important to distinguish between these as they deal with very different aspects of the delivery, but together paint the full picture. Just delivering on functional requirements could miss out entirely on important factors such as usability, scalability and performance – adversely affecting the expected characteristics and attributes of the end product or solution.

On the odd occasion that the stakeholders do not fully understand what they need or want, then it’s up to a skilled Business Analyst to elicit the requirements with a great deal of importance placed upon gaining consensus and approval on the outputs from all the appropriate key individuals. Conflict within project stakeholders is much more difficult to resolve when the project is in flight.

Working to an agreed set of requirements should help set the project on the right course regardless of the management process and goes some way to ensuring a positive outcome.

In the next post, we’ll take a look at the role of a project manager and their management approach. If you need project management help or have any questions, contact us on info@pulsion.co.uk

Standardising on a front-end JavaScript Framework, Part III

Standardising on a front-end JavaScript Framework, Part III

By Scott Miller, Senior Software Engineer, Pulsion Technology

This 3-part blog series was created during the course of investigating which JavaScript front-end framework we should standardise on, with Part I considering the merits and pitfalls of Angular and Part II considering the same for React. This last blog will briefly discuss the other options in the market right now, and then finishes with our thoughts and conclusions.

Other Options

You’d be forgiven for thinking sometimes that Angular and React are the only options out there, in terms of front-end JavaScript frameworks. Although they’re by far the most popular and used ones, there are many more out there. And given how fast the trends in web development can change, who’s to say if next year one of these up-and-coming frameworks will have pushed their way to the top? With this in mind, it would be foolish to ignore them. Among the other frameworks we looked at were Vue, Ember, Dojo, and Meteor.

Conclusion

After weighing up the different opinions gathered from our developers’ investigations, it was decided to choose React as our front-end JavaScript framework of choice, going forward. Why?

  • React is by far the most popular framework, going by the numbers on GitHub. Also, there’s a large number of high-profile clients that have adopted React as their JS client library of choice – e.g. Netflix, AirBnB, Codeacademy, Facebook, Instagram, Atlassian, Dropbox, Imgur, Paypal. Presumably after going through a similar “which javascript framework should we choose” exercise as us, except with a lot more resources.
  • There are plenty of examples of sites migrating from Angular2 to React. None I could see of sites migrating from React to Angular2.
  • Angular has broken community trust by essentially taking a popular trusted JS framework (Angular 1), throwing it away, then re-writing it from scratch. As such, many developers and companies have switched from the immensely popular Angular 1 over to React.
  • React has a low learning curve when compared to Angular 2+.
  • React has a faster rendering time and more lightweight than Angular
  • React has a large support community

This investigation has put us in good stead to push forward and use React for future web development projects, to deliver fast, modern, and reliable web applications that meet the business needs of our customers.

Please feel free to leave a comment, or if you have any questions on this or any other software development topic, then please don’t hesitate to contact us on info@pulsion.co.uk or 0141 352 2280.

Standardising on a front-end JavaScript Framework, Part II

Standardising on a front-end JavaScript Framework, Part II

By Scott Miller, Senior Software Engineer, Pulsion Technology

At Pulsion, we’ve recently been discussing standardising what JavaScript front-end framework we should use across all future web development projects.

However with the wealth of choices of JavaScript UI frameworks out there, this is far from a trivial decision. We decided to focus on the 2 largest players in the market – Angular and React. This 3-part blog series considers both frameworks, our investigation and conclusions. In part I we considered Angular – this blog post will take a look at React.

React is the other current big player when talking about JavaScript frameworks. Although on paper it seems newer than Angular (having only been around since 2013, rather than Angular which has been around since 2009), when you factor in that Angular 2+ is essentially entirely different to Angular 1, then you realise that Angular 2+ has only been around since 2016. Which makes React much more of a mature platform. It’s made by Facebook, and has been battle tested by Facebook in their own live environments since 2011.

React code is a bit of a culture shock for someone (such as myself) who’s never seen it before and is more used to an MVC approach (having worked heavily with Angular 1 and ASP.NET MVC in recent times). The reason for this is that React doesn’t separate HTML mark up from JavaScript (unlike Angular), and instead combines HTML and JavaScript together. While proponents of MVC (such as I was) may cry that this isn’t separating concerns adequately, I eventually realised the truth is that there *is* a good separation of concerns in React, it just has a different focus: the separation of concerns being component based. And from that point of view, it works. So all the individual parts of a webpage are broken down into small components, and all the mark up and functionality for each component is grouped together into a single React file.

A big advantage with React is that it is really easy to get going with it, the learning curve is pretty low. Part of the reason for that is that React is just a front-end JavaScript library, rather than a fully-fledged framework the way Angular is: so it’s more lightweight. This does mean that you need to use other complementary components alongside React: for example, a routing component and an implementation of Flux (which is the design pattern used for data flow in React applications). Arguably, this gives more flexibility in deciding what components to use for developing your web application: you aren’t just tied to the components that come with a fully-fledged framework such as Angular.

React has markedly better performance than Angular 2+. Part of this is down to the fact that React is so lightweight, and partly down to the fact that React uses a virtual DOM to minimise the amount of information that it needs to update in the browser with every webpage refresh.

One of the things that disappointed me most when looking into React was the lack of definitive coding standards, the way can be found in Angular (for example, John Papa’s excellent Angular style guides). But then again, React is still a developing framework, with new features and changes being made regularly, so perhaps a definitive set of coding standards for React is still to come.

In part III of this blog series, we’ll briefly discuss the other options available, and then offer our conclusions. Meantime, please feel free to leave a comment, or if you have any questions on this or any other software development topic, then please don’t hesitate to contact us on info@pulsion.co.uk or 0141 352 2280.

Standardising on a front-end JavaScript Framework, Part I

Standardising on a front-end JavaScript Framework, Part I

By Scott Miller, Senior Software Engineer, Pulsion Technology

Introduction

When planning development for a new modern-day web application, it’s hard to conceive of developing it without using JavaScript. Indeed, as time goes on JavaScript plays more important a role in web development, regardless of what your development language of choice is. And, as is the way of things in the modern world, it all changes so quickly. Here in Pulsion, we’ve recently been discussing standardising what JavaScript front-end framework we use across all future web development projects, regardless of the back-end language used for the website (be it .NET, PHP, Python, whatever). But, with the wealth of choices of JavaScript UI frameworks out there, this is far from a trivial decision. You have Angular and React as arguably the biggest players here – and then others such as Ember, Backbone, Vue, Meteor, and the list goes on. Over this 3-part blog series, I shall discuss our investigation and our conclusions.

Overview

Now, in an ideal world, we would work on a few enterprise level web applications using each of the popular modern JavaScript frameworks, and then based on the extensive experience we’d gain from those projects, we’d decide on what one we preferred for future projects. But, as is too often the case, this world is not ideal. So the approach was taken of getting a number of developers of differing levels of experience and different language backgrounds to do some investigation into the different frameworks, the pros and cons of each, and then to combine that information, together with their past experience, to come up with an overall recommendation on what one we want to use for future projects.

Angular

The first version of Angular was extremely popular: it was widely adopted by the tech community, which was aided by it having the backing of Google. In Pulsion, we’ve developed a number of web applications using Angular 1 in recent years. Overall, it was found to be very responsive to use, and pretty easy to pick up. The MVVM pattern it used was familiar to anyone who had worked with any kind of MVC framework in the past. However, it did have its drawbacks. It was found that directives in particular were really not intuitive. Also, if you had a number of different nested layers of scope, things could start to get confusing really quickly! So it was with this background that we looked into the modern version of Angular (version 4 at present, version 5 currently in beta).

The first thing of note is how different Angular 2+ is from Angular 1. It’s essentially a completely different framework, which has simply retained the Angular name. They’ve moved Angular to using TypeScript, using a component architecture where each component will follow MVC/MVVM pattern. The use of TypeScript means it’s easier to write better code, and the component architecture means it is easy to re-use code. It also has a marked performance improvement compared to Angular 1.

There did seem to be some down-sides to Angular 2+, however. Although it’s easy enough to write a basic demo app, there looks to be a fairly big learning curve involved if you’re going to be getting into the complexities presented by an enterprise level web application development project. In addition, the 2-way data binding that is used by Angular can be as much of a curse in some scenarios as it is a blessing in others. It’s great if you’ve got a simple webpage with a few fields. However, if you’ve got a complex webpage consisting of nested components with lots of inter-dependencies in fields, it could become very easy to lose track of exactly what the 2-way data binding is actually doing, behind the scenes: it simply becomes “magic”. And to a developer, “magic” isn’t good!

In part II of this blog series, we’ll take a look at another JavaScript front-end framework that has become popular in recent years: React.

Meantime, please feel free to leave a comment, or if you have any questions on this or any other software development topic, then please don’t hesitate to contact us on info@pulsion.co.uk or 0141 352 2280.

Pin It on Pinterest