The web makes it possible for people–regardless of whether they’re document authors or document recipients–to participate in the process in new, creative and highly effective ways. But it also requires that we step back a bit and view things in entirely new ways.

Because of the web and software as a service (SaaS), authors can design new documents or edit existing ones without having to have software installed on their local hardware. Among other things, this adds a new dimension to the phrase, “taking your work home with you.” Critical customer-facing documents can be created quite literally from anywhere, at any time.

The web also means recipients don’t have to receive their important documents only via envelopes delivered by their national postal service. They have the luxury of receiving critical information via print, email, web, smartphone or mobile device.

But let’s consider for a moment the concept of delivering documents to smartphones and mobile devices. While everyone–users and vendors–like to talk about alternate delivery channels, clearly these devices might not seem to be appropriate for the delivery and reading of entire documents. Let’s use insurance documents as an example.

While it’s arguable that delivering lengthy, complex documents, such as insurance policies, to mobile devices isn’t practical. But the delivery of key components of the document–for example, information about important changes–prior to mail delivery of the entire thing is not only practical, from a customer experience perspective, it’s imperative.

This sort of integrated approach would also make the delivery of other, less complex documents, such as policy application or policy change forms, not only practical but highly effective.

If, for example, policy application forms delivered to mobile devices used by agents or prospective customers were fully dynamic–meaning they could present the viewer with different options based on selected check boxes or radio buttons–and could be filled in and signed, the information could be captured immediately and passed back to the insurer’s core systems. This would speed up the onboarding process, reduce reliance on costly and time-consuming OCR-based processes, drive down costs and enhance the customer experience.

Data captured in this manner would increase the speed with which policies could be printed and delivered to the holders via the traditional postal process.

For another example of how mobile delivery could improve the customer experience, let’s look at the case of transactional documents, such as premium notices. If users who are in the process of designing new or editing existing notices could identify specific areas of the document–let’s say, the recipient’s name, account number and the amount of the premium payment–to be delivered to the policy holder’s smartphone or mobile device it would help the insurer stay in touch with the policy holder, improve customer service levels and, again, enhance customer experience.

As in the previous example, this could be an interactive experience where the message containing the information could also ask the recipient to acknowledge the message and ask them to respond if they have any questions or issues. In an integrated approach, the insurer’s customer service group could have time to address the issues before the premium notices are printed and mailed. Improved customer service and engagement are again the goals of this approach.

These scenarios show the up-sides of this brave new world. The downside, of course, is the fact that if left to itself, any system that empowers non-technical users and delivers critical customer documents via multiple channels could easily result in chaos, if not properly managed.

So, clearly being able to manage it all (just like back in the early days of digital print) is paramount. And this demands that while authoring, approval, delivery, customer involvement and so on are distributed far and wide, documents and their components–content, data, etc.–reside and be managed in one, central repository.

Gone are the days of having someone design forms using local, desktop software and saving those forms–whether they’re still in development or completed–in a local or shared drive using an ad hoc naming convention. I know it sounds cliché, but there’s always the possibility that that person won’t be available (the old, "what happens if they get hit by a bus?") just when you need them the most.

These issues can most easily be addressed by a centralized repository governed by a management system that assigns user roles, responsibilities and access rights, establishes form and document naming conventions and is integrated with a production environment that supports multiple delivery channels.

Obviously capabilities such as these wouldn’t be of much use without robust reporting functions. Management’s ability to easily and in real-time view the status of forms, documents, users and recipients is the final component that prevents the threat of chaos.

Using an insurance example again, a sales executive who is planning the rollout of a new policy or the penetration of a new market would find it extremely helpful to know exactly when the forms and documents that support that policy will be ready. Similarly, a financial executive whose plans rely on the timely rollout of that same policy would need to know exactly when they can expect the company to begin appreciating revenue from it. A properly architected system would support these needs as well as others.

Just as technology silos don’t make much sense in today’s world, reporting silos are equally counterproductive. In the first part of this series, I talked about how technology can allow your printing operations to know absolutely the status and condition of print jobs down to the piece level. I’m suggesting now that that technology should be integrated with the reporting functions of the central repository.

This would give all authorized users–management, authors, even clients in the case of service providers to view the status of a document throughout the communication process–whether it’s under development, in a master library, in production (print, email, web, smart phone, mobile) and even if it’s a form that’s being viewed by recipients on a website or tablet.

Some folks struggle to see all of the implications and complexities of document design and use. But the issues are legion. Without a plan that views the entire process and takes advantage of available technologies and considers the possibilities of technologies to come, we face the prospect of ever-expanding landscapes and the risks of chaos. Management insight or chaos–it’s your call.

Scott Bannor began his career in digital communications in 1980 and has held sales, marketing and product management positions with a number of industry leaders. He joined OBRIEN in December 2012. Contact him at scott_b@obinc.com.