On Jan. 29, I ordered three custom-made gifts, with three different ship-to addresses, from an e-commerce site that also has a thriving catalog business. Because the products were handmade, all three were shown as backordered. But the expected receipt dates still made it possible for them to be delivered by Valentine’s Day, and I’d had good service from this company before.
When Valentine’s Day came, however, confusion ensued. According to the Website, two of the products had shipped on Feb. 4, but in actuality only one arrived – even though both were to be sent to the same region of the country. Making matters worse, I received a backorder notice postmarked Feb. 11 stating that the shipping date for both gifts had been changed to March 8. As for the third gift, which had been backordered until Feb. 10 and had to travel four times as far as the others, it arrived on Feb. 11.
When, on Feb. 15, I inquired about the mix-up, both the Website and the customer service rep indicated that the products had shipped. But the purchasing system portion of the order processing system still showed an inaccurate expected-receipt date. This was what had triggered the company to send the backorder notification cards.
And there we have an example of what can happen if your Web application and your catalog management systems are not integrated.
Unfortunately, integrating your Website into your catalog business system is not as simple as “plug and play.” As Sharon Gardner, vice president of management-systems software provider Smith-Gardner & Associates, puts it, “The dilemma in integrating the catalog business system with e-commerce is in deciding how much of the data required for the Web application must be duplicated in both systems, how to integrate the data between channels, how to keep them fresh, and how to keep the customer informed.”
The three key decisions
The level of integration that you wish to achieve will affect the accuracy of your data and, of course, your costs. Up-front capital expenditures for tight integration and high site functionality could range from $150,000 up to a couple of million dollars. You’ll also have to consider the ongoing operating expenses and organizational changes that will be necessary to manage a multiple-channel business.
But there are other factors besides cost that you should consider when determining the optimal means of integrating your Website and your mainstream catalog business. You need to make three key decisions:
1) What functionality and service levels will you offer on your site?
Your vision of how the site will work – what you will offer on it and how the customer will interact with it – will have a big impact on how you integrate the two channels. Web customers need access to merchandise descriptions, prices, shipping and handling fees, and sales tax calculation. Then there are additional functions that have become associated with Web shopping: Shopping carts, instant messaging, live chat with customer support, and links to other sites are among the myriad options.
You need to review your existing operations to ensure that they can support the needs of your Web-based orders and customers. For instance, most e-commerce companies recognize that they must respond to customer e-mails within 8 hours and that a performance goal would be a 2-hour turnaround time – if not less. And will you offer guaranteed shipping if the order is placed by a certain time?
The specific functions you deploy will determine how often the data must be transferred between the catalog management system and the Website application, and in turn, the degree of integration between the two. If, for instance, you are going to make product stock status available to online customers as well as to your call center reps, both channels need frequent – perhaps close to real-time – data updates so that the information is accurate and consistent. Order and return status should be updated frequently as well.
You also need to make sure your customer account status information can be transferred quickly and frequently. You likely want your site to have access to up-to-date credit information from the catalog system so that it can decline to process orders from house-account customers who have reached their credit limits and instead refer them to the credit department.
Keep in mind, however, that while failing to transfer data in a timely fashion results in poor service, too much data being passed in real time can overwhelm your system, leading to poor system performance and even operational paralysis if the hardware doesn’t have enough capacity. So it’s important to assess just how much traffic your infrastructure can handle, and to prioritize which data need to be transferred most frequently.
Of course, all this transfer of data will inevitably create some redundancy of information. Which leads us to our next key decision…
2) Which system will drive which processes, and which will “own the data”?
This question is the equivalent of “Who’s in charge here?” Which system should be the dominant one? The answer, in our view, is the catalog business system, by virtue of its greater sophistication and capabilities.
Developers of “storefront” Web tools – self-contained software packages that enable Websites to sell merchandise – will no doubt disagree. They want their systems to control the data and the processes such as credit authorization. And it’s true that they are developing an exciting array of applications. But the storefront tools do not contain the total package of information systems. Catalog business systems, on the other hand, offer a breadth of corporate management functionalities and a unified view of the company across all channels, which makes them the clear choice for driving the processes and owning the data.
The diagram on the next page illustrates the typical functions of a catalog management system and an e-commerce system. The orders, inquiries, customer information, and item information represent the major transactions that flow between the two systems.
The Website software has customer contact data such as name and address. But the total, multichannel view of customer activity resides in the catalog system. This system maintains all the order and customer return records and their associated line items, each with a status and date stamped as an order is fulfilled or a return is processed. Additionally, the customer management module archives the customer diary notes of recent inquiries or complaints. There may also be marketing data indicating preferred-customer status, prior purchase categories, and lifetime value, to name a few.
The ability of the catalog management system to contain interchannel data has another benefit. Today’s customers have the option of choosing either Website or catalog channels as the spirit moves them. Often the customer may abandon or suspend the Website order midstream and instead e-mail a question or call customer service. A unified customer management module allows the call center’s service reps to interact with the customer across both channels and view the total activity.
Interchannel customer files are just one area in which the breadth of the catalog management systems will be invaluable. The same will hold true for the other business system functions. You’ll want unified reporting and processing for credit and collections, marketing, merchandising, inventory management, purchasing, financials, and operations.
3) What degree of integration do you wish to achieve between the Web application and the catalog business software?
Let’s say an online customer inquires whether an item is in stock. The management system hosts the product number, the product description, the offer code, the item pricing, and the inventory availability, yet all this information must also reside as subsets of redundant data on the Web application in order to provide a response to the query. What’s more, the information that flows between these two applications must be synchronized periodically.
In the catalog business system, the merchant can view the quantity of goods on hand by item, and can also see the forecast, the demand to date, and the shipped sales by channel. As new vendor receipts are processed through the fulfillment center, the catalog business system’s inventory file is updated, and the merchant can decide the allocation of inventory.
In a similar fashion, the Website must be able to show the customer when backordered products are expected to be available. This means that the Website must be able to access and reserve product from future purchase orders. Those purchase orders are maintained on the catalog business system, which must update the parallel Web application periodically, as purchase orders are created, maintained, or received against. Obviously, the more tightly integrated the systems, the more quickly the customer can receive an answer to his or her query, and the more accurate the response will be.
The three integration scenarios
Right now, three scenarios are being played out by businesses that have established both catalog and e-commerce entities:
1) Manual rekeying of data. The Website prints out the orders, and employees manually re-enter the orders into the catalog business system. This is a slow and unwieldy arrangement, and not suitable for a site that has high volume or whose Web-savvy clientele expects immediate gratification. Generally, inventory availability, pricing, and product information is inadequately updated in this set-up.
Yet this is how numerous companies launch their e-commerce endeavors. It’s fast and inexpensive up front, but it’s also labor-intensive and therefore costly in the long run. And it exposes the orders to human error; it’s easy to rekey the order information incorrectly or to lose orders altogether.
2) Periodic data transfer. With this hybrid approach to integration, some data transfers are performed in batches and others in real time. The Web application typically synchronizes its tables with the business system at specified intervals. Some data, such as item availability, should be updated more frequently than others. Volume may dictate batching of these transactions. On the other hand, inquiries such as order status or catalog requests may be processed in real time. This is a faster and more efficient arrangement, but it involves more expensive interfaces and still does not offer true real-time information throughout.
Companies with high volume most often use this set-up. In fact, it’s the most commonly used automated data transfer system today. Order volume and inquiries typically drive the frequency of the batch transfers; during peak times, companies transfer relevant data more frequently to expedite customer service.
3) Near-real-time data transfer. In this, the highest level of integration, every transaction flows between the Website and the business systems instantly. Customer service soars with this option, and choosing it might seem like a no-brainer, but it, too, has its limitations. Chief among these is stressing your resources and the capacity of your infrastructure. Real-time integration is best used by companies with lower order volume, or those that can keep up with the transaction volume.
Implementation time frame
To support your systems integration decisions, you need to be sure that your organization is ready to implement them conceptually and culturally. This may mean redefining your concept of customer service. For example, your call center may need new staffing and software to respond to e-mail correspondence.
From a fulfillment perspective, if the item is in stock, most catalogs can fulfill customer orders by the next day. Expedited freight orders are picked and shipped the same day with a 3 p.m. cut-off. Pure plays are having a much harder time getting these best practices in place – but you shouldn’t.
Another part of customer service is making sure the system works before unleashing it on the consumer. Allowing adequate time for implementation and testing is key here.
Catalog package providers have streamlined implementations so that industry-accepted software such as MS SiteServer and IBM Net.Commerce can be integrated in as little as eight weeks. Integrating an inhouse legacy system with one of these packages, however, requires custom application programming interfaces (APIs) and interface programming, which may take a little longer. And some of the more advanced e-commerce packages (such as Broadvision) can require two or three times the effort. The entire process, including testing, can take as long as eight months. You need to factor this time frame into your integration plan.
On the communications front, you’ll need 56kb and T1 lines to facilitate data transfer between systems; these can take 8-12 weeks to install. Finally, configuring Web servers and firewalls can take an additional two or three weeks, but their importance cannot be overlooked.
It’s a new era of merchandising. Effective integration of the new and the old, of your Web application and your catalog management system, is critical to achieving the higher levels of customer service that the market now mandates, and to maximizing sales between channels.