Getting Ready for a New Ecommerce Platform

By Mark Eckman

A company had planned for a new commerce platform.  The RFP made sure the chosen solution and vendor partners met their needs.  It developed a sound business case, refined metrics and created a fantastic project plan.

Over months, the company had completed designs, developed a compelling user experience, created technical interfaces for dozens of systems, tuned a database of SKUs, and configured the platform for maximum performance.  It had trained technical and marketing staff in classroom sessions and handed out certifications.

When it went live with its new site, there were no major glitches.  Success!  Two months later, when the euphoria had settled, project sponsors checked progress against the initial business case.  Site revenue and gross margin were millions of dollars behind the business case.  What went wrong?

Analysis revealed that while marketers had been classroom-trained, they were not using the new system properly.  They were operating as they always had and were not taking advantage of their site’s new testing, marketing and promotional capabilities—capabilities which were critical for realizing the conversion and order value improvements that had justified the seven figure investment.  For all of its pre-launch planning, the company had failed to fully consider change management – and how to really embed behavioral marketing routines.

As commerce platforms become more powerful and ubiquitous, companies are realizing that post-launch business readiness is a serious issue.   A successful site launch doesn’t necessarily lead to economic success.  While many organizations consider their technical needs, and take steps to cover site development and technical maintenance, many fall short in areas such as release planning, content management, product data, promotions, merchandising, on-site search, analytics and/or operational troubleshooting.

For an ecommerce system to be successful, metrics must tie to the initial business case and additional corporate objectives.  Measures should go well beyond launch date, page views, and revenue and be communicated to a large group of stakeholders.  Before choosing a platform partner, discuss with them their approach to facilitating this kind of planning and tracking exercise.  The best measures establish clear guideposts to be assessed 30, 60 and 90 days after launch, and also outline an ongoing measurement and dashboard approach.

There are four broad areas in which commerce platforms typically go wrong.

1.    Failing to plan holistically.  This is difficult to do well.  However, if it isn’t done effectively, errors can suddenly show days or weeks after a site is launched, leaving the company in the difficult situation of modifying software or processes on the fly.  An example:  A company failed to plan for handling pricing changes in relation to multiple markets and customer sets.  No one noticed it the day the site went live.  Ten days later, a manager went to change pricing on an SKU for a customer subset and discovered he couldn’t do it.  There was not an elegant and automated way to execute this fine-grained exception processing.

Seemingly small errors can have large consequences in terms of providing customers a holistic marketing experience.  The problem becomes acute when dealing with multiple merchandisers, bricks-and-mortar stores and regions.  Bridging online and off-line business is hard to keep in synch; business readiness planning needs to account for the details.

2. Failing to manage scope migration. While organizations with sound project management practices usually guard against “scope creep,” scope migration can be more insidious and harder to pin down.  During the design phase of a project, most companies will earmark a certain budget for features or enhancements so that, if changes or extensions are needed during the course of the project, those changes will be considered “in scope” up to a certain budget level.   Program sponsors expect that new features will support a project business case, such as improving a customer experience or improving important metrics.

Scope migration typically occurs when there is a disconnect between project sponsors and the front line managers making day to day platform design decisions.  Too often, feature budget is allocated toward “pet projects” that may not move the needle against the project business case.  Common sources of scope migration include extensive customizations of content designed to solely support brand marketing initiatives; advanced rich user interface features that only appeal to a very small segment of customers; and specific features designed to placate merchants, product managers or field sales.  There can be very good (often internal political) reasons to allow scope migration, but the cost and business case impact of those decisions needs be acknowledged well before the site launch.

3. Failing to fulfill the business case.  In planning, companies will estimate conversion rates, establish A/B testing tools, do training and take essential steps… and then forget them.  The site launches and marketers go back to old ways of doing business without using new tools effectively. The relief of a successful launch obscures the fact that business needs to be done differently.  It is hard to remember that a site launch is the beginning and not the end of the business process.  As hard as a launch is, breaking old habits and applying new tools can be even more difficult.  Senior marketers should seek appropriate help, and must ensure they have leadership, business and technology organizations in place to deliver against their clearly defined measures of success.

4. Failing to agree on metrics before launch.  When that happens, direct and indirect stakeholders impose their own standards or skew metrics they use.  This sets off a merry-go-round of blame, meetings and delay. In one case, client project leaders decided that two seconds was an acceptable load time for a feature-rich page.  The elegant design and extensive java script were deemed critical to deliver the right user experience for a key customer segment.  Executives not directly aware of the project decision criteria were soon fuming over the two seconds.  How could the managers have done that?  What were they thinking?

Another common error is a failure to explain to stakeholders the differences between old technology and new.  Web analytics packages, for example, can use slightly different algorithms for the same site metrics.  In some cases, metrics will look better, or worse, based on engine differences.  A manager often will take old metrics, throw them into a spreadsheet with the new ones without adjusting for algorithm differences, then claim triumphantly that the old site was better if the metrics show negative differences on the new site.

There is no such thing as too much communication in business readiness before site launch.  Managers in charge of the launch have an obligation to keep everyone, including secondary and tertiary stakeholders, abreast of what they are doing and why.

Remaining narrowly focused on getting a site up and running is guaranteed to produce errors that are costly to the company, and maybe even to one’s career.  An effective organization helps with critical pre-launch “PR” around internal and external awareness, and effective governance helps define a longer-term channel roadmap—well before a launch leads to warring factions clamoring for their next set of must-have features.

Mark Eckman is managing partner of Rosetta.