The paradigm of multi-channel delivery has been with us for a number of years now. Briefly, it refers to the ability to communicate with your customers using a number of paths or "channels," such as paper/mail, email, web viewing, mobile device, interactive voice response and so on. Most of these new channels have focused primarily on the delivery of data or content, such as accessing your checking account through your smartphone. Yet, an area that has been left out of the discussion is the difference between "content" and a "document" and how this difference affects the ability (or even the desirability) of multi-channel delivery.
Content is a broad term referring to data of any type. Content can be text, numbers, images, audio/video recordings—anything created by one party to communicate some type of information to another party. In the world of transaction documents, "content" is frequently seen as a listing of transactions. For example, on a credit card account, on any given day, a consumer may use a mobile device to view the transactions posted up to that point. There is no legal consequence as to the accuracy of this list—if a transaction is posted tomorrow rather than today, that's just a matter of inconvenience, not error.
On the other hand, a "transaction document" is the unique fusion of fixed and variable data at some point in time that has been brought together to create an entity that has financial and, often, legal significance. Think of that credit card account. The credit card statement at the end of the month is a legal agreement between you and the company. If you fail to pay the minimum amount due by the due date, the company can charge you late fees. If, on the other hand, you have the right sort of card, you may be able to pay the full amount by the due date and avoid any fees or interest on purchases for that month.
In either case, this credit card statement has to be correct because "there is money riding on it," if nothing else. If the company fails to list a transaction through its own error on the end-of-month statement, then you are not liable to pay for that transaction that month, nor can they charge you interest on that transaction if you otherwise paid the full amount within the grace period. In other words, what is important is not the data or content that the company has in its computers but the information encoded in the transaction document when the unique fusion of fixed and variable data was created and sent to you.
The result of this understanding is that the transaction document should be treated as "persistent," that is, once the transaction document is created, it should never be "recreated." Whereas content is, by design, usually served up dynamically in order to reflect the most current data, a transaction document is, by design, not served up dynamically but is always the same original copy re-presented. This is true in order to prevent errors creeping into the dynamic re-presentation of the information in a transaction document, if that document is also recreated.
Of course, in some industries, the layout or "look and feel" of the transaction document may be regulated, such as for certain parts of insurance policies in the United States. Thus, the company may be liable not only for errors in the data within a transaction document but also for changes in the very layout of the document itself.
HTML and XML languages are normally used in the dynamic electronic presentation of content on web browsers and mobile devices. These are lightweight languages that permit the quick presentation of content on a variety of devices with quite different attributes. The downside of using these languages, however, is that it's difficult, if not impossible, to guarantee what the customer will see on the device. The very flexibility that these languages offer on very diverse platforms assures that the presentation will invariably change.
It is for this reason that transaction document producers normally use PDF as the presentation format. PDF, being at its heart a print stream, like PostScript or AFP, assures that the customer sees a transaction document with the same "look and feel" on any platform, even if the customer prints the transaction document locally. Indeed, it is for good reason that PDF means portable document format. However, the ability to easily view PDF on some mobile devices may be practically impossible, given that the transaction document in PDF is usually based on a US Letter or A4 medium—specifications that are far larger than some mobile devices.
Thus, in the near future, it seems virtually required for most transaction document companies to communicate with customers not only through multiple channels but with presentation formats geared to the requirements of those channels. This may limit the ability of a company to provide all content and all transaction documents via all channels. In these cases, the company must clearly communicate which content is dynamically generated and which content is document-based.
WILLIAM MCCALPIN is registrar and co-founder of acadami, the transaction document educators. He is also principal and co-founder of MHE, which specializes in the product, strategy and technology issues in the area of the communication and presentation of information via electronic printing, imaging and the Internet. He has more than 30 years experience in software development and consulting. For more, email registrar@acadami.org.
