When you have a sitewide sale event, do you have an easy, quick and reliable method for getting these sale prices into the system? Similarly, when the sale is over, are you able to bring back the old pricing (or update it with newer pricing) in the same manner? If you are using a Product Information Management system worth its salt, the answer to both questions should be a resounding and firm “Yes!”.
Whether your pricing is on the simple side (a single price field, or a few price fields) or more complex (many price fields, tiered pricing, zone pricing, event-specific pricing, etc.), the process should be roughly the same. Your pricing fields are managed in a spreadsheet, with each SKU or Item as its own row, and this is the file you use to bring this pricing into the Best PIM Software.
Why Excel?
Well, any spreadsheet software is fine, really. Excel is by far the most popular one, so people almost use it interchangeably with “spreadsheet software”. There are a number of advantages to keeping your pricing in a spreadsheet:
1. You can perform advanced pricing calculations (such as % off, markdowns, markups, etc.) against any number of SKU’s quickly.
2. It is a fairly universal format and easy to read and manage. Just about anyone who owns a computer has some sort of spreadsheet software installed.
3. Any number of pricing files can be saved so you can rollout pricing quickly. For example, you may have a Halloween sale pricing that affects 5,000 SKU’s. That spreadsheet with those specific SKU’s can be kept ready and imported in time for that sale. Meanwhile, you may have a Black Friday sale spreadsheet with the same or additional SKU’s, all with completely different pricing, ready to be imported at that time. Essentially, you are just managing multiple spreadsheets, one for each specific sale.
An Example of a Simple Pricing File
Below, I am showing a simplistic example of what a pricing spreadsheet actually looks like. In this specific case, we are looking at the simplest case possible: a single pricing field. The file, therefore, only contains two columns: the first for Item # or SKU, and the 2nd for “Price”.
If you wanted multiple pricing fields, such as List Price, MSRP, etc., these would just be additional columns in the file. But it works exactly the same way.
Export Out Existing Pricing
Through the Product Information Management system, the first thing you probably want to do is export out all of your existing items and price values. This becomes your “backup” in case any bad price values get loaded. It can also be used to quickly revert pricing once the specified sale period ends—provided pricing hasn’t changed in the meantime.
The generated file should, of course, be in the same spreadsheet-readable format that the Importer would use (such as tab-delimited text).
If your items are broken down differently within your PIM, you should be able to export each individual collection of items and their pricing as individual files. This will make it easier for you to manage and mass update the pricing later.
For example, you may have an upcoming flash sale event for “Automotive Accessories”. You don’t want to update or manage your entire line of products, just those that belong to Automotive Accessories. The PIM and DAM systems should allow you to easily do this, so now your pricing spreadsheet has a relatively few items in it—just those that need to be updated for the flash sale event.
Bring It Back In
Now that you have your pricing spreadsheet(s) updated, you need to have a mechanism to get that data into the system quickly when it’s time for your sale event to go Live. This would be the Import feature within the Product Information Management system.
Now that you have your pricing spreadsheet(s) updated, you need to have a mechanism to get that data into the system quickly when it’s time for your sale event to go Live. This would be the Import feature within the Product Information Management system.
Can It Be Automated?
The scenarios we discussed above are well and good if you are trying to do a manual import—that is, one involving a spreadsheet and a human initiating a process. But, what about a case where you’d prefer your backend ERP system to automatically bring that pricing over for your sales events?
The scenarios we discussed above are well and good if you are trying to do a manual import—that is, one involving a spreadsheet and a human initiating a process. But, what about a case where you’d prefer your backend ERP system to automatically bring that pricing over for your sales events?
Typically, these are done on a nightly basis at a time when the fewest users tend to be active in the system. It can be set, however, to run as often as you need, exactly when you need it. A manual import can still be run at any time to override this automated pricing, also.
