• Fax Broadcast Guide

  • by Steve Hersee

Copia is currently the largest provider of private and Commercial Broadcast Fax software. There are large service Bureau's that are larger, but they have internally-developed Software. Copia provides fax software solutions for customers needing 2 to 99999 phone lines.

This chapter will cover all of the design issues for selecting and running a fax broadcast system. After reading this chapter you will better understand the problems and how Copia has chosen to solve those challenges.

Why Fax Broadcasting?

When the Internet became the big new in 1995-96, people were saying that "fax is dead". The people that saw the power of the Internet were sure that the Internet would kill off all fax use. Well because of the success of "SPAM"(sending email to people you don't know and trying to sell them your stuff), fax is coming back with a 20% growth per year. Let me say why I think that the Internet has not been able to kill off faxing.

First, to paraphrase a line from SaraLee, "Nobody doesn't like fax". The people that use fax every day, like it. It is easy, quick and most people have a good experience with their first use of the fax machine. This is NOT the case with computers.

The second reason that the Internet has not "Killed" fax, is that email is too familiar and personal. When you receive email, you do not get a logo, or any graphical information. You do not mind getting email from your friends and co-workers, but most people are put off by email from strangers. When you get an email from a "stranger" and they are trying to sell you something, it is called SPAM. Even though you have not wasted paper to print the email, you may have to wait for the email to be downloaded and the you spend the time to read and then delete it. When you get a fax the amount of time that you use to decide that it is a "junk" fax is less than spent in trashing an unwanted email.

When you talk to sales and marketing people about using the Internet instead of fax, they are not happy with the email decision. With email you do not get any graphics. With fax you get a full 8 1/2 by 11 inch page of information. This is much like a full page ad in a magazine. Sales and marketing like the full page better than a screen's worth of plan text as delivered by email.

The best and final argument for fax vs. email is that it gets results. Copia once send a short, single email to a list that we got from a show. This single email broadcast brought us no leads, and a number of what I would call fragile people that were ready to go up to the top of a building with a rifle and start shooting people, because they got a single "unwanted" email. They also made statements that they would rather buy an inferior product than to do business with a company that uses SPAM.

Well as a person that wants to sell a product and have happy customers this kind of reaction to a marketing plan is not welcome. On the other hand we have people who have tried a fax broadcast tell us that the results were amazing. The responses were much better than they had expected. The number of "Sales", not just leads were well beyond their expectations.

Copia Does Fax Broadcasting better than anyone else.

To say that we do Fax Broadcasting better than anyone else is a large boast. Then let me see if I can cover how Copia has been inventive in solving the faxing problems that you can think of now and the many other problems that you have not yet thought of. The Copia FaxFacts product is about "no limits" faxing.

Copia's History in Fax

Copia was the first company to provide a Fax-On-Demand system as a software product. Copia released FaxFacts in November 1989 at COMDEX in Las Vegas NV. Copia FaxFacts systems have been in continuous operation since 1990.

Copia was the inventor of the same call Fax-On-Demand system, and was granted a US patent for this invention. In 1990 the fax and voice boards handled only a single line and we had to develop a system that could share the load across multiple CPU's.

The early design decision enabled the fax load to be shared. This early design has paid off for our fax broadcast systems, by allowing very large systems to be installed.

Some of the questions you need to ask yourself in planning your broadcast sytem are:

*** Is it scalable? ***
Can additional CPUs be added to deliver faxes and can additional CPUs be added to help with the rasterization process, in features such as mailmerge.

As we continued to work on the Fax-On-Demand system, we decided to hand-off "faxback" requests into a general queue. This queue was then processed by all the CPUs acting as "fax servers". The queue is NOT a file, but a directory that we call "TOSEND". One of the most important design specifications of the FaxFacts system was to be an "open" system. When you create a queue that is a file with records in the queue file, you now have to provide an API to allow outside programs to send faxes. Each programming language needs its own API.

Copia reviewed the work that was done by GammaLink on their Gammafax product line. Copia supports the entire Dialogic/Gammafax productline along with Brooktrout, and others. Terry Flanagan decided early on to store the information needed to send fax in a normal ASCII file. Using a file to store all the information that would normally go into a "queue record" has many pluses and some negatives. With an ASCII file per queue request, we have the ability to write a request to send a fax from any programming languages. The essence of the FaxFacts API is the following information written into a file:

$fax_phone 630-778-8848
$fax_filename mytiff.tif

The above file is written to the tosend folder and given a unique file name. The FaxFacts Engine controls the broadcast process in each CPU that has fax boards in that CPU. The FaxFacts Engine looks for files that are not claimed in the TOSEND folder. When the Engine finds a file in the TOSEND folder that is unclaimed it starts to send the file named in the file to the phone number specified. When the fax is sent the file is then moved from the TOSEND folder and placed into the SENT or FAIL folders. This has the advantage of the TOSEND folder constantly being emptied by the Engine. The The file stores additional information such as the failure code or the CSID of the receiving fax machine. This additional information can grow without the limits of field size that a queue record would impose.

The design of our file-based queue also removed the need to have to pack, compress, or run maintenance programs on the faxing system.

*** The system duty cycle should be 7 by 24 ***
This means that the system should not have files that grow and then need to have programs run to "clean-up","remove gas","pack deleted", or "make faster". Some systems can not be run for days, week, or years with out having a person adjust something. Copia has designed FaxFacts to run for years without any "operator intervention"

Why Three kinds of fax broadcasting?
With FaxFacts, a broadcast can be one of three (3) ways. When you send the same image to a list or group of people, we call that a fax blast or simple fax broadcast. If you want to increase the reader attention to the fax, you can do a Graphical Coversheet broadcast. With the Graphical Coversheet broadcast you can place database field anywhere on an image template (we call this a watermark). The result is a fax that is sent with the basic message and the variable information from your database overlaid onto the watermark. Each field can be positioned size, font and angle can all be setup using the visual fax viewer to design the final fax. If you need even more power you can do a Mailmerge to fax using the FaxFacts FFMERGE system. The Mailmerge system is unique to Copia in the way that we have approached the problem, more later about FFMERGE.

Fax Blasting
While FaxFacts is a great Fax Blaster for people that have just two phone lines, we are much better than the others when it comes to larger numbers of faxes to send. Earlier I said that FaxFacts is the "no limits" faxing systems. What that means is that when you want to Blast Fax to 1,000, 10,000 or virtually unlimited number of recipients.

*** When Blasting is there only one copy of the fax? ***
Many systems have to have a separate image for each person that is going to receive a fax. This causes the system to have to create, move and/or use more disk space for each fax receiver. With FaxFacts each receiver gets a small file that contains the name of the fax image to be sent. This saves time and space on the disk. Using the FaxFacts Fax Blaster we can launch 100-150 faxes per second.

This means that you can launch 9000 fax blasting requests per minute! This does not mean that you are sending 9000 faxes per minute, but that you have queued 9000 fax requests. The launch speed only becomes a problem if you can not launch faxes as fast as you can send them. How many lines would I need to have sending faxes to keep up with 9000 faxes per min? If you figure 45 to 60 fax pages per hour. You would have to have about 9000 phone lines to keep up with the launcher.
With "no limits" faxing, when you launch a blast fax you are not limited by the file system as to how many faxes can be launched. When you launch a blast fax under FaxFacts the only limit that can be reached is when the "file server" is out of disk space.

Graphical Coversheet Broadcast

The next type of broadcast faxing is what we at Copia call Graphical Coversheet broadcast. This type of blast fax is designed to increase the readership of direct mail via fax. This is also called "junk fax". It is only a "junk fax" if you are not interested in the information in the fax.

People will read a fax that has their name on the fax. I think that most of you have seen a direct mailing that had your name in the body of the sales pitch. This same effect can be done with Copia's Graphical Coversheet blast fax. We have had good luck placing the name of the person we wish to read the fax on a 25-degree angle in a script font. It says Steve, I thought you would be interested in this info. This makes it look like some friend of mine saw the information, wrote a note on it and faxed it to me. The chances of me reading the fax are much greater when my name is written on the fax.

There is a story on how the Graphical Coversheet product came to life. In the Fax-On-Demand market one of our competitors had the ability to construct a fax from data and images. This required programmer like coding and was not visual. We needed to meet that requirement, and we also wanted to improve the "look" of the coversheets that were produced by the system.

The original coversheets available in most faxing systems, had a logo followed by the ASCII font provided by the fax board supplier. This font was UGLY. It also could not be compressed or any of the other format options that users had become used to using in Windows. The Graphical Coversheet program was a process that ran before the fax was sent and the ASCII information as far as date, time, sender, and memo information was overlaid onto a watermark logo sheet.

The Graphical Coversheet monitor ran on the server and produced a temporary work file that included the watermark plus the variable information to produce a pretty coversheet. After the Graphic Coversheet system was working, our customers asked if we could do a blast fax that used the graphical coversheet to increase the readership of fax blasts. We said sure and we were well into "direct mail via fax"

We have since added many features to the formatting capabilities of the Graphical Coversheet system. We have customers that are actually Using the system as a forms processing system. This is easy because you have the ability to position any field on the watermark image to within a 200th of an inch. Customers are using this to fax back forms, invoices, and email to the closest fax machine.

Graphical Cover
[Graphical Coversheet]

Mailmerge to Fax

Copia's real strength in fax blasting is our FFMERGE product. This is the single strongest reason to select Copia's fax system over all of the other solutions in the marketplace. Why am I making such a strong statement? Let me explain.

During a show in London, Tim Frost and myself were driving (on what seemed to me the wrong side of the road) back from London to Tim's home near Stonehenge west of London. We were well into solving people's problems with faxes. We had been asked if we could do mailmerge to fax. Well we could not at this time do mailmerge to fax.

The problem with mailmerge to fax is how do we get the information from the wordprocessor when one fax stops and the next one starts, and how can we pass the information of the fax number and other information. We were aware of other solutions that use DDE(Dynamic Data Exchange), vendor specific API calls, and embedded keywords. Tim and I were not happy having to develop WORD Basic programming to do the interface to the fax system. We also thought that the system would not be reliable if it had to look for key words in the print stream. We wanted it to be easy to use, and to work with any of the wordprocessors out in the market place, and we wanted to be sure that it would work without us having to buy and test one of every word processing packages that has been released.

As we talked we came around to thinking about being able to do the equivalent of an OCR operation on the fax number. Now we both knew that OCR was a lot of work and would slow down the system. We then came to the thought of doing our own special TrueType font. But instead of catching the font on the way into the windows conversion to graphical raster lines, we would look at the graphical raster lines as they came out of the rasterization process.

We designed our font to have a line at the top of the character and a line at the bottom of the character. Just under the top bar we put a binary code that we can decode into the actual character. We took advantage of the following information. A 12-point font is the same as 10 characters per inch. At 200 pixels per inch for fax images that gives us exactly 20 pixels or dots across each character. We make the overbar 18 dots across the top and bottom of each character. The overbar allows us to "see" our font at the start of the page.

When we "see" our font we are able to read the next scan line and decode it directly into the information needed. This line we call the "firing line" and it contains the fax number and any other information that we wish to pass from the printing system to the faxing system. By only having to look at the top information to find the "firing line" the rest of the printing process goes along at full speed. The FFMERGE printing speed to create the ready to fax tiff image is 30 to 60 pages per minute. (this differs from the 100-150 mentioned earlier)

Let's see how well our invention of FFMERGE meets our design goals:

Is it easy?
Yes all you have to be able to do is get your mailmerge running to paper, then place the fax phone number field at the top of your mailmerge form letter. Set the font to the FFMERGE font that we supply and set the size of the font to 12 point. You are now down with the setup of FFMERGE.

Do we have to program?
No because we are looking at the print stream as a print driver, we do not know or care what windows application that is being used. We now do not have to purchase and test each and every word processor on the market. The customer is not bothered by needing to get operational the "macro package" for each new version of the OS or word processor.

What databases do you support?
This is a common question that we get with our mailmerge solution. Because of our design getting our information off the printed image, we support any database that the word processor you are using will support. Again, if you can print it, you can fax it.

Do you support the latest version of Word?
Yes, If the system prints to Windows and you can control the font selection, you can use FFMERGE. (Copia was issued patent number 5,715,069 on Feb 3, 1998, for the FFMERGE product)

*** Sure we can do mailmerge, NOT ***
We have had a number of people come to us saying that they purchased a product that could do mailmerge. BUT whenever an application, for example MS-Word, was upgraded, this seemed to cause problems for their mailmerge software. Also some implementations tend to slow down as the size of the mailmerge grows.

I have had reports that the time for each page at the start is very quick, but after 1000 records the system was so slow that it could not keep up with the number of outbound lines sending faxes. Just because the vendor says that they can do mailmerge to fax, be sure to ask if it works with current tools and the latest OS. Also what are the defacto limits to the size of jobs that the systems "likes".

Mailmerge
[mailmerge screen shot]

After you are amazed at the ease of use of the FFMERGE solution, you will see that it is "pop-up" free and MUCH faster than any of the other systems that are available.

FFMERGE extra credit
After you understand how the FFMERGE print driver works with the True-Type FFMERGE font, what about all the other things that you print? Why would you ever mail something that you print from you computer? With the FFMERGE tool, and invoice, statement, or purchase order can be printed directly to the fax machine of the person that is intended to receive the information.

To me it makes no sense to print a piece of paper, fold it, address an envelope, place postage on the envelope and leave in in the hands of the US post office. I don't know about you but I am from Chicago, we burn mail in Chicago! Using FaxFacts to deliver items normally mailed, gives you access to the receivers fax printer on a 7 by 24 basis. The US mail people have defined "on time" delivery of mail from one suburb to another to be two days.

We are working with people that are pulling up their payment times by using fax and also lowering their costs for delivering paper to other businesses.

Helpful tips and hints:

How many phone lines will I need?
We use as a rule of thumb 45 pages per phone line per hour, for a one page normal mode fax. Even though the fax may only take a minute or less to send, 45 pages per hour is closer to the actual time per line because of busy time, dial and ring time, adding to the time to send a fax. If you are going to be sending more than one page as part of the same fax you will see the number approach 60 pages per hour per line. Or if you are sending High Res faxes to get a better look, the number will drop to closer to 30 pages per hour per line.

How much disk space will I need?
The more the better. If you are using either Graphical Coversheet or mailmerge to fax, you will be creating two files per fax receiver. The TIFF file will be from 30,000 to 100,000 bytes and the control file will be about 300 bytes. If you have a large disk and the file system is FAT, not Novell, or NTFS, you will use more disk space than you expect.

With a FAT(File Allocation Table) file system which was the original MS-DOS file system, even small files may take 32,000 bytes. The problems is when you write a 300 byte file and a 40,000 byte TIFF file, the system will allocate 3 blocks of 32,000 bytes. While the DIR command shows 1000 300 byte files, you will see the amount of disk space go down by 1000 times 32,767 bytes.

On a Novell system the allocation block size is 4096 bytes per block if you are not compressing the file system. This is NOT due to FaxFacts except that this is one of the issues when you have lots of small files. We feel that the benefits of load sharing and speed overshadow the wasted space due to file allocation issues.

One of the best files systems for the FaxFacts system is the NTFS system that has a typical allocation size of 512 bytes. The 512 bytes is close to the actual size of the control files that we use.

Should I use a service bureau?
Service Bureaus provide a great service, if you wish to send lots of faxes. Copia loves our service bureau customers. By working with our large service bureaus, we have remove some of the brick walls that we hit at the 100 and 400-line system sizes. We currently have systems with more than 600 lines operating as a single blast faxing system. The advantage that service bureaus have over in-house systems is "bandwidth". If you have a fax that you want all 5000 receivers to get the fax within an hour, you will have to use a service bureau. You also get to have someone else worry about keeping the system running and working with the phone company.

But what you do not get is the increase in your telephone volume, and the ability to lower your overall telephone costs for both fax traffic and voice traffic. If you wish to have your fax broadcasting to go out at night on your companies phone lines that are not being used at night, you will have to have a system in-house. Once you have the system in-house, you can then use the system as your LAN fax server, so that your users on the LAN network can use the system to send faxes.

Another advantage is that you can now move the launching of fax blasts directly to the users that want to send the faxes. Most service bureaus do not have the ability to do a true mailmerge to fax. This is much easier to do in-house.

Smart Retries

As we at Copia have been working with different fax boards and customers, we have learned about how to get faxes through if possible, AND not try forever to deliver faxes to number that will never work. We started with specifying a number of retries and a time delay between tries. This is what many of the systems offer. The first problem that we saw that was not addressed by this design, was "self induced busy signals".

*** Does the system detect and prevent it's own busy signals? ***
A "Self induced busy" is when you have more than one person in or broadcast list at the same phone number. We had more than one phone line that was trying to send to the same fax number. When I looked into how other systems solved this problem, I found that they only were able to increase the number of retries to fix this problem.

What we have done is to prevent the problem in the first place. As each phone line selects a file to send a fax, it first checks to see if the phone number is in use by another phone line. If the phone line is being used by another fax line, then the file is skipped, and the retry count is not incremented.

*** Can the system restart in the middle of the fax? ***
After fixing the busy problem we have improved the sending of faxes with what we call "Smart Retries" The FaxFacts "Smart Retry" feature provides enhanced control over retrying failed outbound faxes. With this feature, you can specify that only the un-sent pages are retried if a transmission fails in the middle of a sequence of documents, and you can specify a different pattern of retries for different classes of failure.

A special cover sheet can also be specified for retry attempts. The entire system is table driven, so that you can modify the actions that the FaxFacts system takes for each and every failure status that is returned from the fax board system. You can choose to retry specific error codes or fail them and not retry more than once. One use of this feature is to have the fax be retried, if it is busy or ring no answer, after an 8 or 12 hour delay. This will allow faxes to be delivered to those fax machines that are out of paper or turned off in the evening.

*** Is the system automated? ***
Auto fax broadcast launch
The Copia FaxFacts system as always been focused on being able to have the system "run itself". One of the great features of Windows, is that it is visual, and graphical. The graphical nature of faxing is great for Windows and the mouse is great for working with fax images. The problem with the Windows/mouse interface is that it requires a human to move the mouse. In addition to the visual tools to launch and manage fax broadcasts, FaxFacts also has automation versions of the tools.

The automation tools allow fax broadcasts to be launched from IVR, email, receiving a fax, and time of day. Many of our service bureau systems have completely automated the launching of customer broadcasts. The customer first uploads the list and image via fax, BBS, or email/web. Then customer then receives a proof fax and time to call up an IVR port and kill the job if the proof is not of the quality needed. The FaxFacts system options allow IVR input prior to receiving a fax. The IVR information collected specifies the list, priority, and time to send the broadcast. The customer can also call into the system and get the progress of the job either via IVR voice playback, or a faxed status sheet.

*** Do Not Send (DNS) Block fax numbers ***
The system needs to have a central ability to block fax numbers. The FaxFacts system has a, high speed, lookup table that has the list of all phone numbers that are to be blocked. The FaxFacts system has two levels of fax number blocking. There is a central DNS file and then when you launch a blast fax you can specify list or customer/group blocking lists. Our service bureau customers have central DNS files and customer specific DNS files. This is a big issue due to the federal law that can cost you $500.00 for each fax that you send to a person that does not want to receive faxes from you or your company.

Fax Application Programming Interface API

The fax broadcasting software that you buy MUST have some kind of API (Application Programmer Interface). Having the API will make sure that the system will be able to grow and meet your future needs for faxing. Some systems try to use a "standard" interface, such as CAS, or the GammaLink API. The FaxFacts API is a higher level API that is the same API for CAS systems, GammaLink, Dialogic, and Brooktrout.

The highest level API from FaxFacts is the FFMERGE system. All that is needed for a programmer to send a fax is to be able to print the fax number at the top of the printed document. The programmer can also specify attachments and other information on the FFMERGE "firing line". Using the FFMERGE print driver and font to control faxing is very powerful in the hands of a programmer. The benefit of this high level API is that it does not limit the choice of tools that can be used to do the job.

The next level of API gives the programmer all of the control and feedback that is needed. The FaxFacts API is easy to use, has many defaults, and has all the power that programmers ask for. Now for an example:

In the file PO980315.fs
$fax_filename \\faxserver\copia\temp\po980315.TIF
$fax_phone 6307788848
$fax_status1 2 ;ready to fax
$fax_origin user_request
$fax_user \\faxserver\copia\fax.usr ; group file with defaults

When the programmer writes the above file from their application program, they can monitor the progress of the fax. Once the file is written to the TOSEND folder, the sender will know when the fax has been sent when the file is removed from the TOSEND folder and moved to the SENT or FAILED folder. If you do not want to monitor the fax directly, you can specify a "post-process" program to be run by FaxFacts when the fax is "complete". By "complete" that means that the fax has been sent, or that it has completed all the retries specified and is being move to the FAIL folder. FaxFacts customers use the post-process to send email back to the sender. The post-process is used to update databases or to do what ever work needs to be done when the fax is complete.

If more control is needed, additional API commands are available.
$fax_cover -- sets the coversheet to use if needed.
$fax_header -- sets the line at the top of each fax.
$fax_pre-process -- Specify the routine to run before faxing.
$fax_post-process -- Specify the routine to run after faxing.
$fax_retry -- Set override retry settings.
$fax_send_time -- Set the send time in the future.
$fax_send_date -- Set the send date for the fax.
$fax_send_line -- Specify the line or line group to use to send this fax.
$fax_sender -- The name of the sender of the fax.
$fax_receiver -- The name of the fax receiver.
$retry_cover -- The coversheet for restarted faxes.
$var_def -- Define a user variable for the cover sheet.
$voice_phone -- Call out for IVR or pager.

A more complex example:
$fax_filename t:\faxfacts\image\00001154.1
$fax_cover t:\faxfacts\copia.cvr
$fax_header "To @ROUTETO From: @SENDER"
$fax_sender "Dorothy Gaden"
$fax_receiver "Ann Other"
$fax_send_time 17:00:00
$fax_phone 3105553218
$fax_status1 2
$fax_post-process "exchange_send" internal
$fax_origin user_request
$fax_user t:\faxfacts\fax.usr
$var_def ToCompany "Other Company Inc."
$var_def data1 "recid1000"
$var_def user "email address"

Smart fax boards vs. low-end fax boards.

Copia's FaxFacts system supports the high level fax boards from Brooktrout, GammaLink, Commetrex, and Intel/Dialogic. The high level fax boards have a computer for each telephone line. The computer on each phone line helps keep the remote fax machine happy that the sender has not stopped sending when the main CPU may be busy.

With the low end modems, when the main CPU becomes distracted, the remote fax machine may think that the sending fax has stopped sending and drop the line. This causes a higher failure rate and more phone costs. The larger issue is that if you have problems sending to a specific fax machine and the low end fax board fails every time, who do you call to fix the problem?

The problem is that on the low end modems there is very little that the supplier can do to fix fax problems. With GammaLink and Brooktrout they have downloaded firmware that they can and will fix. Now that all of the fax boards send the same faxable TIFF files, you now can use the common API from FaxFacts and even mix fax boards from different manufactures in the same system.

Fax-On-Demand

FaxFacts also has as an option Fax-On-Demand. Unlike other systems that have added FOD as a late add-on, FaxFacts started as a FOD system. Many of the high end Dialogic and Brooktrout fax boards can do both voice and fax on each phone line. FaxFacts gives you the option of having Fax-On-Demand, IVR, Voice broadcast, Fax Polling, Internet faxing, dialer faxing, web page faxing, faxing from your web page, and faxmail. FaxFacts has more features in the FOD area than any other FOD vendor.