Driving B2b eCommerce Application Adoption and Utilization

Easy access to online app builders gives the impression that creating eCommerce apps is easy — however creating a successful B2B eCommerce Application is anything but easy.

Andrew Johnson, former Apple employee specializing in helping App developers succeed, sheds some light on the process of B2b eCommerce application adoption and deployment in this article.

 

Designing a B2b eCommerce application isn’t cheap. Developers and Business Development professionals spend months and sometimes years perfecting the code and thinking of the end user experience enhancements in the lab. Most organizations don’t consider that when the app is finally completed the hard work begins. While working in business development at Apple I saw enterprise-wide software platforms launched over and over with great fanfare, only to find that usage dropped off dramatically several months later? In many cases, poorly planned application deployment caused a very useful app to be shelved or decommissioned due to low user adoption within a year of its announcement.

So how do you motivate employees and customers to embrace and use newly implemented applications, such as a new order app, order entry enhancements, sales tracking CRM or wholesale applications? It’s not easy and the adoption and utilization strategy must be baked into the development and refinement of the app all along to deliver the promised results and drive quickly through the change management process.

Over the years, I have been involved in numerous B2b eCommerce app deployment programs to facilitate software launches. Regardless of the apps purpose of whether the software is for ordering, sales collaboration or some other business use – there is a process to help organizations have a higher chance of a successful launch, to kick-start wide-spread user engagement and to increase the chance of sustainable, scalable success in employee and customer adoption of the platform.

Think of Waves of Adoption and Plan

There are four waves of adoption. First wave are customers and employees who have been clamoring for a new process and have demanded a technology solution to the problems the app is attempting to solve. These are called First Wave Adopters and they are low hanging fruit. The app must succeed with this group for there to be any level of success long term. The second wave are employees and customers that are comfortable with technology, but they also are fine with the status quo. Third wave adopters are not comfortable with a new way of doing business and must be managed closely through the change management process and finally the fourth wave are active detractors of a new way of doing business and will find any reason not to adopt and utilize the technology.

Early Collaboration

When an application platform is selected or being written it’s important to involve and engage every level of end user to solicit feedback and discuss the most important benefits that the application will deliver. Creating a sense that the application is for the people by the people is important to have buy in and dedication from the user base.

Make it Exclusive

Plan for exclusive content for the app. This will help drive mass adoption but not utilization. Adoption is the first step in a longer process of change management and utilization of technology.

Use Early Adopters to Drive Second Wave

Share the successes of other customers and employees who derive the benefit of the technology quickly and easily. Share the real stories and offer to introduce the users to the wider user base community.

Use the Technology

How are you supposed to drive adoption into the employee and customer base if your senior team isn’t actually using the technology themselves. Senior leadership and earlier adopters must constantly showcase how the technology works by using the features and functionality on a daily basis.

Change the Status Quo

Employees and customers that are in the process of adoption should be treated differently than they were in order to understand the change that is taking place. For instance, a new B2b eCommerce order app is distributed to a wholesaler’s customer base. These customers should have shorter, more frequent visits from a sales rep. During these visits the sales rep will make sure the conversation changes from the order details to a sales-based dialogue.

Bend But Don’t Break

Even if there is significant resistance to change don’t shelf the idea for good. Continue to show the benefits of use throughout out the day by solving problems that are brought up by the user base using the technology. When you know it’s right for your employees and customer they will thank you later when they come around.

The software or technology itself is not the primary factor for making a project successful – it is your ability to communicate effectively to your employees and customers about the program and help them through a process of change by using the software or technology in their daily work.

This is a process of change management. Look at and learn from the most successful cases of change management in history.

Shell – changed it’s process when reserves were at an all time low leadership introduced Shell Downstream-One to better communicate about how the crisis would be presented by all employees. By identifying and rapidly addressing the many areas of resistance that emerged – such as that some influential stakeholders stood to lose control or market share – adoption was accelerated. Shell is in a significantly healthier position than when the transformation started, and by that measure the program has been deemed a success. And the ramifications of Downstream-One continue to result in ongoing change.

In the late-1990s, industries around the world were becoming increasingly alarmed that all software would reset itself on 1 January 2000. Fear spread, and a generation of businesses was set up to address this impending crisis, known as Y2K (Year 2000). In the history of business, no change management program has galvanized businesses like Y2K. The consequences of inertia were all too clear. In this instance the success of organizational change – supporting the delivery of crucial business strategies – was driven by a common and effective organizational change requirement. The emphasis had to be on rapid implementation, and leaders had to avoid the temptation to try to deliver value from change. This was all about ensuring that solutions were found and implemented in time. Organizations had to be agile enough to act at short notice.