If your company uses EDI you probably understand the need to maintain consistent and accurate ‘transactional’ records. But EDI is a limited number of fields and the company comptroller probably has it all under his or her thumb and allocates resources to its maintenance because it makes money (or more importantly loses money when done badly). EDI doesn’t really require “updates” because of the question/response nature of transactions flow. It’s all pretty simple unless you’re responsible for it, because an error means something is shipped or not, paid for or not. You and your trading partner notice quickly.
If it only was so for ONIX files! Just like EDI an ONIX file is an electronic resource, used to support business to business communication. While it’s not used to communicate transactions, retailers use the information in it to sell and expect the information in the ONIX file to be correct and updated. The price on their on-line retail site is probably sourced from your ONIX file, as well as the publication date and availability status (not to mention the author and title!), so if you cancel a title and don’t update or simply stop sending the title’s ONIX record, the retailer may be trying to sell a product that will never be available.
Consumers seem to think that the on-line record should match the book they order, shipping departments think that the book weight should too, and the buyer thinks the carton quantity should be accurate.
Well, duh! Like you didn’t know that? And you probably know why it’s not quite right, too. I mean I know some links on our website are down—I really need to fix them and that’s not happening either!
There are not really clear guidelines on what constitutes a proper update routine and the answer changes radically between a poetry publisher with a slow growth list and nothing OPed in 20 years, and a multinational whose books can come in and out of print in a season, but here’s some guidelines:
Retailers rely on book metadata be it for the initial buy (6 months before publication), transactions (active titles), and customer relations (accurate titles and descriptions). Each on-line page describing a book is like a little contract with the consumer—maybe not written quite in stone but it should be treated that way.
ONIX suppliers, by supplying book metadata should make a commitment to accuracy, and be willing and able to update it if it changes. This is different from including enhanced data—that’s different and just as necessary to maximize sales. I mean the basics: title, author, subject, imprint, publisher, status, pub date, supplier, availability and expected ship date all should be accurate, maintained fully utilizing the relevant ONIX composites so that name and title are parsed out, the publisher and supplier names are consistent, etc. etc. If it’s wrong it should be fixed and re-sent.
Frequency should be as often as it’s needed—for big companies that might be weekly “deltas” (change only) with monthly (full files), medium companies can probably do monthly files and small companies quarterly. But everyone should make an effort to realistically maintain and update their ONIX records and resend them regularly. A full file of all active records should be submitted to your supply chain trading partners at least once a year—and more often probably makes sense too. It’s not enough to issue a record once and expect 5 years later that retailers know it’s still active. It’s not enough to never clean your file of the books you no longer support either.
And yes, when a book is out-of-stock and reprinting you really should tell retailers when it’s due to be available again. If you really don’t know then fake it: maybe give a date 3 months away and keep updating it—it’s better than saying nothing until the reprint is ordered and restocking is 2 weeks away.
When books go inactive—Out-of-Print or No-Longer-Carried, what-have-you—you should also maintain records and release them appropriately (aren’t I cunningly vague about that). There’s no need, once the supply chain knows their status to continue to send them, but give everyone a chance to update their records before you drop them. And then maintain a file so that it’s available on request. Whoa! A lot of this information would be useful internally too!
It’s not easy to do and it takes thought to set up the internal communications—but it’s not necessarily that hard either. It’s a breeze in comparison to what agency pricing is going to be like. And how were you planning to communicate that? (New codes in ONIX should be in place by March by-the-way.) It’s only going to get faster.
The more astute of you might be thinking, I bet this harangue about the need to do the obvious well is a lead up to BNC BiblioShare. And you’re right!! There’s a webinar “Introduction to BiblioShare” on the 24th of this month… 2 to 3:
http://biblioshareintro.eventbrite.com/
and it’ll be available after the fact too.
