MISTAKE #1: Developing a Web-to-print system that relies on programmers for creating document templates.

We've talked with lots of people that have done this. Most of them regret it. Here's why:

It is mostly a matter of economics. The main issue is this: If your programmers need to be involved each and every time you want to create a new document template (i.e., a new kind of document), creating a new template will be a time-consuming and expensive process. This situation creates job security for your programmers, but the costs that you'll need to pay for each new template will be high — and if your programmers are busy, you probably won't be able to get new templates onto the system quickly enough to satisfy your customers.

Because your template-creation process will be expensive and slow, you won't be able to compete effectively in the marketplace, because other companies that didn't make this mistake will be able to get new document templates onto their Web-to-print systems quickly, easily, and inexpensively.

How can you avoid this mistake?

Avoid this mistake by purchasing a well-designed, off-the-shelf, state-of-the-art Web-to-print system that comes with drag-and-drop template-creation software — or by subscribing to a hosted (a.k.a. "ASP") system that has drag-and-drop template-creation software and/or is operated by a company with skilled people on staff that can create new templates in a timely manner.

A well-designed system will have a rich set of features that allow a non-programmer to

• use industry-standard applications (such as Adobe InDesign, QuarkXPress, etc.) to do most of the design work for your templates
  
  
• embed formatting information and complex conditional logic into a template.

A system like this generates template files containing built-in intelligence that does two important things:

1. automatically creates the Web pages for the customer interface that's needed for the template.
   
   
2. allows the documents that are based on the template to to print properly.

MISTAKE #2: Using one kind of software to create files for on-screen display & proofing, and using another kind of software to create printed documents.

Look at it this way:

If you're going to show a document on the screen and tell your customer that it is a "proof," then it had better look exactly like the document that will be printed. Otherwise, you might have an unhappy customer.

The only way to ensure that what you show on the screen really looks like what will be printed is to use the same document-composition engine to create both the on-screen documents (proofs) and the printed documents.

We have talked with lots of people with Web-to-print systems that use two two different document-composition engines: one for on-screen display & "proofing" and another for printed documents. All of them are unhappy with this situation! Among different document-composition engines, there are subtle differences and sometimes not-so-subtle differences in the way that fonts are managed and rendered, in the way that word-wrapping is done, in the way that line-spacing is handled, and more.



MISTAKE #3: Not having control over the template-creation process.

This issue was addressed when we discussed MISTAKE #1. We'll just touch on it again here.

Lots of Web-to-print implementations are commercial failures because it takes too long and/or it costs too much money to get new document templates onto the system. When you're choosing a Web-to-print system, be sure that you understand the template-creation process and are comfortable with it.

If you are going to reply on your own employees for creating templates, make sure the employees have the proper skills and training.

If you are going to rely on another company to create new templates for you, be sure they are adequately staffed, adequately trained, and prepared to dedicate resources to creating templates for you when you need them.



MISTAKE #4: Selecting a Web-to-print system that doesn't work well with the printing equipment you plan to use.

You need to make sure the document-composition engine that's used by your Web-to-print system can generate an output format that is compatible with the printing equipment that will be used to print your documents. Otherwise, it might take much too long to print the documents — or worse, you might not be able to print the documents at all!



MISTAKE #5: Choosing a poorly designed Web-to-print system, or choosing a Web-to-print system that hasn't been tested adequately.

Web-to-print technology is young, and some companies are selling Web-to-print systems that don't work well, either because they are poorly designed, because they haven't been tested adequately, or both.

Insist on a trial period during which you can test the system to make sure it works the way it is supposed to work and to make sure it works well for your purposes.



MISTAKE #6: Failing to plan for page-imposition and document-finishing operations.

Are you planning to use your Web-to-print system to create postcards? Business cards? Saddle-stitched booklets? Calendars?

Generally, documents like these require extra workflow procedures. Specifically:

When people are printing postcards, business cards, or other kinds of small documents, they usually do imposition so that they can put more than one document on a page; then they cut the documents apart after they are printed.

And when people are printing saddle-stitched booklets or calendars that are folded in the middle, they need to do imposition to rearrange the pages properly for bookletting. Also, the booklets and calendars usually need to be stapled.

Make sure your Web-to-print system can handle these extra workflow procedures. If you plan to do in-line finishing, make sure your Web-to-print system can interface properly properly with your printing equipment so everything will work smoothly for you.



MISTAKE #7: Hosting a Web-to-print system in-house without adequate skills, training, and resources.

Some Web-to-print systems are "self-hosted" systems while others are "ASP" systems (also known as "SaaS" systems).

As the term implies, a self-hosted system is a system that runs on a computer at your company, or — if not on a computer that's physically located at your company's facility — a computer that is under your company's control.

An ASP system is a system that runs on another company's computer. (The company on whose computer the system runs is referred to as an Application Service Provider; hence the abbreviations "ASP.")

ASP systems are usually a lot less expensive than self-hosted systems. In spite of this, though, some companies feel they want to host their own Web-to-print systems.

There are many reasons why it's a good idea for some companies to host their own systems. Note, however, that if you decide to host your own Web-to-print system, you should make sure you have what's needed to handle it properly. For example:

• Does your company have a fast and reliable Internet connection?
  
  
• Are your personnel properly trained in network administration and Web-site administration?
  
  
• Are your personnel properly trained in security-related topics so your server can be kept safe from hackers?
  
  
• If you've chosen a Web-to-print system that requires a dongle (hardware key), will you be able to install the dongle on the computer you're planning to use for the Web-to-print system? (This might be a problem if that computer isn't physically located at your company's facility.)