A Business Technology Place

Practical advice for educating employees about your eCommerce platform

There are two groups of people in your eCommerce organization that are on the front-line of dealing directly with customers each day: the help desk and the call center.  Yet when we think about the software development release cycle, it’s easy to focus all of our attention on the planning, development, and testing cycles for release management  and forget about the people who provide operational support.

The work to keep the help desk and call center in the know is not difficult, but it does require periodic and intentionally focused effort. There are a few things I’ve learned over the years to help keep the front line up-to-date.

1. Make sure they are on the distribution list for release notes

You may release distribute release notes via a blog post, email, forum, group ware, etc. The point is to make sure the help desk and call center are hooked into your distribution method. The purpose of the release notes is to inform the two groups about incremental changes taking place with the eCommerce site.

2. Schedule a full site review at periodic intervals

Since the help desk and contact center may have higher turnover than some areas, it’s a good idea to offer full site reviews for new employees. I’ve seen full site reviews as a series of screen shots as well as a live demonstration of the site.

Screen shot documentation is useful to have for reference, especially if there are screens that are several clicks off the typical purchase funnel path. But the screen shot compilations are time consuming to maintain and easy to push to the back of your “to do” list. So you have to carve out time to do it.

Regardless of if you update such a document with each release it is good to have an off-line screen capture document created at least once each year so that you maintain a historical archive of screen flows. That makes marketers and historians happy when they want to peer into the past.

There are a few important aspects to capture in the full site review to give the help desk and call center targeted information that they may need to resolve customer questions:

* How the customer finds information for additional help. This might include email, eChat, FAQs, and the phone number listed. Pay particular attention to the FAQs. They are often forgotten and may contain outdated information.

* Who to contact if product information needs to updated. Customers may often want to get clarification on the product description or specifications. If the eCommerce product page contains incorrect product information or could use an adjustment, the help desk and contact center need to know who the product manager is so they can have it updated.

* How pricing works. Make sure the agents know how pricing works on the site, especially delivery pricing.

Other important questions will come up during your review that are specific to the content and flow of your site. A full site review also gives you a chance to hear about voice of customer concerns directly from those who talk to the customer. So you can expect to learn things you didn’t know, or really didn’t expect to hear about how customers are using the site.

Software Release Management. It’s more than an IT thing.

This is about IT and Business alignment.
I’m fortunate enough to have worked in two different functional areas of a business: IT and Marketing. I can say with 100% confidence that business owners and stakeholders of software releases should be more concerned and involved in the IT release management process. The typical release process covers areas such as requirements specification, feature prioritization, business case modeling, and go-live deployment communication. It’s a set of tasks intended to oversee the requirements, development, testing, and deployment of software releases. Sounds very IT, but it should be a shared business process.

Release management is about adding value.
Release Management is also about how IT and business owners engage in communication that benefits the stakeholders and customers of the business. A business owner could be the CFO, CMO, product manager, finance manager, procurement agent, etc. It’s someone who champions and justifies the contents of a release. An engaged business owner has a chance to more positively influence the results of the release.

I’m not saying they need to know all the details of the software development cycle. I am saying they need to help with defining the process such that it maximizes the potential of the organization. One of the key traits of a successful leader is making success achievable by others. They can do this in the software development cycle by making sure that the process is free of unnecessary work and is efficient in how often work is output.

Mike Sutton and Tym Moore provide a great list of practical ways to improve software release management for CIO.com One key point of Sutton and Moore is that establishing a regular release cycle is vital because:

  • It creates a predictable timetable for when stakeholders can expect to receive functionality. This creates confidence and allows the team to focus more on the content of the release.
  • It creates a routine for all functional teams to align their efforts.
  • It gives clients confidence that your business is regularly delivering new value to the marketplace.

Think features, not projects.
Here’s the rub. To get to regular release cycles (such as every six weeks), your software development process needs to focus on delivering features of work rather than projects of work. Projects by definition have a variable level of scope which means that delivery dates will also be variable. Content for regulatory requirements, compliance issues, new features, or defect fixes are easier to deliver when they split into several smaller units of work effort. It’s a similar the concept of memorizing larger lists by “chunking” the list into smaller groups.

That’s a paradigm shift for many traditional project organizations. But it’s a way to encourage lightweight processes and focus more on delivering value to the client quicker. Salesforce.com discusses release cycles that were becoming longer and delivering less before they turned to a process focused on smaller and regular releases. They saw an immediate increase in the number of features delivered per team and a reduction in the days between releases. Amazon.com, the largest online retailer, also uses regular release cycles.

At then end of the day it’s about efficiency and work output.
Automated machinery is installed on plant production floors for this very reason. The machines produce units of output at predefined intervals. This maximizes value to the business and clients. Our software release output should aim to be the same way. It’s definitely more than an IT thing. It’s just good business.

Communicating go-live deployments

The work of eCommerce deployments doesn’t end with go-live sign-off.
If you work with eCommerce platforms then you know the happiness of after go-live deployments. The actual events of go-live deployments can be an adventure when unplanned events ‘happen’. But the work doesn’t end with the final sign-off and completion of the deployment plan.

There are a series of tasks after deployment.
One important step is to gather information from listening posts such as voice of customer collection areas. The success of the deployment is really based on how the customers use the system. Unwritten and unspoken voice of customer responses are visible by monitoring the key metrics of the site such as conversion rates, average order value, number of items in the cart, etc.

Don’t underestimate the value of communicating the success to other stakeholders.
I’m not referring so much to the confirmation email that usually goes out to the project team and direct project stakeholders. Certainly, that is an important communication to send. It let’s everyone know that the project team has successfully deployed the new release and that customers are now able to take advantage of the new features.

But there’s a way to get further benefits out of the release by notifying other company stakeholders and customers. This communication summarizes what changed and the value it provides to the customer. In other words, what problem did it solve.

Company stakeholders love this type of communication. It’s a group win that shows a team successfully navigated processes, approvals, and company friction to create something that adds value. People like sharing good news with others, especially clients. So a success communication is often shared again through forwarding. It’s the original viral communication within an organization.

Keep the communication simple and on point.
A good release communication  is simple and shows the changes visually. Often times this is done through a blog post or an email. The communication should be written in common language to engage the audience best. I like avoiding charts, tables, and highly structured templates.  (It’s not a specification!)

The communication should be upbeat. Let the customer know how excited the team is to deliver value to them. It’s why the team works and this work is a reflection of the team and the commitment to customer value.

Defining an eCommerce Operation – Experience and Usability

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my seventh and final post in the series on the topic of defining an eCommerce operation. Certainly I’ve not covered every detail or function of an eCommerce grouped tasked with operations,

eCommerce Operation

An eCommerce Operation Team Structure

maintenance, and new growth. However, this and the previous posts provide a baseline of the most important functions needed in an eCommerce model and provide guidance on the eCommerce team structure.

The area tasked with defining the customer experience and usability of the site is of utmost importance. This part of your team defines the flow of the site, the visual appearance,  and how customers interact with it. The important thing to remember is that to the customer, they are not interacting with your site. They are interacting with your brand. Your eCommerce site is an extension of your brand. It can find, make, keep, and lose customers based on the experience they have with your site.

The experience and usability of the site can be molded in four key areas of release management.  They are prototypes, mockups, use cases, and process maps. They fit logically together and in sequence to guide the designer and implementors in the final output.


The prototype is used to show the concept of a software program or release. The eCommerce team could use a basic functional piece of software, a sequenced set of pictures, a storyboard of hand drawings, or any other type of visual output to display their prototype. The idea is to gain acceptance of the software concept and to create discussion about it to help mold and shape the final output. I know many traditionalists will argue that a true prototype must be a functional piece of software. I do believe this is valuable, and one form of a prototype, but today with today’s tools we have the ability to link static pages together without necessarily making them functional. Remember, the key purpose of this step is to communicate an idea or concept to stakeholders.

In some cases, the prototype is used as a proof of concept. Can the design team make something work on a smaller scale so that it increases confidence it can be done on a larger scale. In this case, the prototype is important in order to secure funding for the software release.

Use Cases

The use case describes how a system responds to actions on it. In an abstract sense we can think of objects performing actions on the system and then specifying how the system will react.  The objects could be people, other programs, or events.  The objects are often called actors and the use case creates a series of steps that describe the action and the resulting response from the system.

The use cases have value because they help the designers and testers to craft the expected flows of the system.  A use case document is also typically easy to read and less formal and verbose than many traditional requirements documents.

It should be noted here, that my good friend Mike Cottmeyer tells me the proper name in agile development methods is “user story“.  Looks like in the case of a user story, the documentation of the requirement is simplified but requires and additional step of documenting an acceptance test.

Regardless of the methodology used, remember the key task with this work is to define the expected use of your system. Define who will use it, how they will use it, and what they expect to see as the results.

Process Maps

Once you have established use cases for a release, you can combine all of them with a process map, or flow chart.  This document defines how all the pieces of the software will fit together and flow to make a complete system. It shows how various use cases may be linked, describes decision points, and shows the possible paths through a system.


The mockup is a way of designing the user interface of system through images or drawings. The mockups are not functional. The purpose of the mockups are to allow your designers to create the page layouts that comprise the system. They’ll be considering things like object locations, form layouts, colors, fonts, etc.  Don’t discredit the importance of this step. Many a A/B test has proven that things like the color of button or location of an object on the screen can have impact on your site conversion rates. You don’t necessarily need a designer for this task, but you do need someone who is visual that can bring your process flows to life.

I added the experience and usability functions to the concept map for an eCommerce model that I’ve discussed.  I welcome your feedback and input.  No model is ever complete and in the spirit of continuous improvement I’ll always be looking for ways to tweak to so that it creates more value.

Defining an eCommerce Operation – Release Management

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my sixth post on the defining elements of an eCommerce Operation. Previously, I’ve written about management in the areas of solution ownershipcontent managementproduct management, demand management and metrics management. In this post I’ll explore elements related to release management activities.

Release management provides for the justification, prioritization, and specification of software that comprises your eCommerce portfolio. Certainly software development is a discipline unto itself, but these elements cover the basic disciplines and functions of the process. This area of your eCommerce operation needs to focus on the ability to get work started, the ability to prioritize a lengthy queue of requests, and the ability to specify what to build.

Business Case and Modeling

Business case activities are mostly used for new software development or development that can be capitalized according to Statement of Position 98-1. Business cases will typically cover:

  • Objectives
  • Risks
  • Estimated costs
  • Estimated return

Building a business case is not likely to be the favorite activity of the team. But doing this does provide great deal of value for your organization:

  • Allows you to build financial forecasts
  • Allows you to build a project budget
  • Shows the expected return of the work
  • Mechanism to gain upper management support and resource allocation to your project
  • Removes pet features
  • Keeps discussions on the merits of the features
  • Removes emotion

Software modeling is another term with a diverse meaning and that comprises many disciplines, tools, and methods. For an eCommerce team, modeling can be a piece of the front end project justification. A software model provides a simple representation of the eCommerce release for the purpose of relaying its purpose, meaning and structure. The model may be composed of graphics, wire frames, or flow charts.

Feature Prioritization

Software shops have lists of items comprised of new feature requests, previously discovered defects, marketing tests, and customer requests. Developing a framework for prioritizing all these ideas can be tricky due to office politics, available resources, financial justification, etc. But prioritizing the list is an essential activity because the size of the list is longer than what you can accomplish. Plus you’ll want to make sure you are solving the requests in a proper order. Here a few ideas for how teams might prioritize work:

  • Based on what customers will pay to receive
  • Based on estimated return value
  • Based on level of effort
  • Use prioritization families – Groups of related requirements
  • First in First Out
  • Value to cost – Highest value to lowest cost first
  • Contractual obligations first

Requirements and Specifications

Documenting requirements is another area that’s a discipline all unto itself and their are many alternative methods for requirements specification. The important aspect of this part of your organization is that you have team members that a) know the business b) know your customer needs and c) are flexible to be able to modify requirements with changing business conditions. Rather than focusing on any one particular method, I advocate having the right type of team member on point for requirements gathering and specification. Adaptability to change to is paramount because the needs of the business and dynamics of your environment will change.

I added these elements of the eCommerce organization to the concept diagram that I’ve grown with each post.  This updated image shows the team layout that I have discussed so far.  I have one other area to cover customer experience, so stay tuned. ( Select the diagram to expand it.)

eCommerce Operation

An eCommerce Operation Team Structure