eCatalogs are Just Spreadsheets, What's the Big Deal?!

That's what the owner of a small office supply company asked me back in 1999 when I was an independent supplier enablement consultant and it was taking me longer than he wanted to create his first electronic catalog in Ariba CIF format for his largest customer who started using Ariba Buyer.

Here are the ten things I wish I had said as to why electronic catalogs aren't "just spreadsheets" and a handful of insights that some newer eProcs now have to offer when it comes to eCatalogs.

The end result may "simply be a spreadsheet" but, it's ensuring what's in this spreadsheet that requires due diligence, namely:

1) Appropriate Selection

The catalog needs to contain all things that the customer buys from you and none of the things you're not supposed to sell. If you have the contract to sell office supplies and you've been given explicit instructions to only include office supplies, then we can't include the kitchen sinks. When it comes time to export the item information from our back end system, the export needs to be just for your customer's desired items.

Some of the larger suppliers have been known to insist that their catalogs can't be filtered in an effort to sell more stuff, you don't want to play those games.

2) Accurate Pricing

Obviously the prices for these items has to be accurate. Sometimes the calculation of the sell price can get complicated, e.g. if it's X% off list for one type of item but Y% off for another, and/or if there are a list of most commonly ordered items that are more highly discounted than the rest.

If your customer finds one item that is priced higher than it should be, they'll lose trust and question all our other item prices.

[Fast forward... newer eProcs now support tiered pricing, bundles, configurable/custom options, etc. which can help when if you sell more complicated products and/or services.]

3) Consistent Names

The item names are the first thing that a customer sees in their search results so it's important that they are strong and also follow a consistent naming convention, e.g. Widgets, Small, Pack of 20

Looking at a long list of items that are consistently named makes it easier for the customer to select the right item, e.g. when sorting by item name, like items are grouped together.

4) Rich Descriptions

This is one area where the initial effort/investment up front can really make a big difference in the long run, but it takes time and/or money. If you want to have your items found in search results, float to the top, and help your customer make the right choice the first time... you need rich item descriptions that thoroughly describe your items. You should take advantage of as much space as the customer can support, e.g. if they allow 255 chars, use 'em.

Some suppliers simply export the bare minimum item information from their inventory/fulfillment system which is often cryptic, e.g. WDGT SML 20P. And what's frustrating for buyers is when they look at that same supplier's B2C site, it's often got awesome rich content, but suppliers often have two separate item databases - one for B2C/marketing and one for B2B/eProcurement. :(

[Fast forward... if you're "fortunate" enough to sell items that are of a pretty popular category, e.g. office supplies, consumer electronics, MRO, then there are now rich content providers that you can use to enrich your item information - more on that another day.]

5) Granular UNSPSC codes

There are so many reasons to make sure that the UNSPSC codes assigned to your items are granular AND accurate. Granular meaning that you can't just assign good 'ole "44120000 - Office supplies" to all your items, even the office furniture and computer accessories. And accurate meaning that if you're selling a standard office scissor then you need to use "44121618 - Scissors" which lives under the Office supplies category 44120000 and not the first reference to scissors you see when searching www.unspsc.org

The customer may have purchase requisition approval rules that rely on the UNSPSC code to determine who should approve the purchase request, e.g. IT may need to approve the computer accessory and facilities may need to approve the furniture. Plus, FWIW your customer's reports will be much more accurate, e.g. they'll be able to see how much they spent on scissors, not just office supplies.

[Fast forward... a new consideration is eProcurement systems now have browseable category trees that rely on the UNSPSC to assign the item to the most appropriate category. You want your items to fall under the right bucket and not all get clumped into one.]

6) Images for Every Product

This is a no-brainer - you have to make sure as many of your items (if not all) have at least one nice looking image. They should be professional looking, highest resolution possible, hosted on a publicly available webserver, and assigned to the right item.

And if your customer's eProc supports multiple images, then give them more. Many suppliers don't take advantage of this and just do the min (if that). Make your items shine!

7) Valid Units of Measure

It would suck if you do all this work and then the item/catalog doesn't load just because your internal unit of measure is "Each" and the customer's eProc needs it to be "EA". So you need to ensure that all your items are using the UOMs that your customer supports.

Sometimes customers will simply say use ANSI or UNUOM which makes it easier, others may say use ANSI but only these codes, and yet others may say you have to use this custom list.

8) Internal Part Numbers for Automation

If you want to automate the fulfillment of the corresponding electronic purchase order and have it flow seamlessly into your system, the part numbers have to be perfect. You can't manually create an item in the catalog file called WIDGET and expect it to work. You need to export the part numbers out of your system and only use those part numbers in the catalog.

9) Properly Formatted File

All this has to be exported into a properly formatted file that matches the customer's eProc file format requirements. XLS vs. XLSX vs. CSV vs. XML vs. CIF vs. ETC. Field titles with correct names. Not exceeding each field's maximum length. Ensure all their required fields are populated properly. Maybe having the content UTF8 encoded. This is where it can get a little technical, but it's a one time effort.

[Fast forward... newer eProcs now accept standard CSV files rather than ones that require custom headers and footers.]

10) Automating the Update Process

Fortunately, we didn't have to update this static catalog very often, so doing this once or twice a year was acceptable.

[Fast forward... with newer eProcs now supporting simple CSVs and allowing suppliers to upload via standard sFTP, suppliers are now in a better position to automate the export, any mapping, and upload using relatively simple scripts or product information management (PIM) tools.]

#catalogs #suppliers #bestpractices