A New Billing System
Edward Lipsett
Intercom, Ltd. is located in Fukuoka, handling work between (mostly) the four languages of English, Japanese, Korean, and Chinese. About half of our business comes from Kyushu and the remainder from clients in the Kanto region. In addition to translation, we also do large amounts of design, layout, and outsourced printing.
Since Intercom began as me working as an individual about 20 years ago, it has always used a bill-by-the-output approach to counting and invoicing. I felt then, and still do, that since the content can have a massive effect on the output volume, billing for the actual number of keystrokes involved makes sense. This stance was no doubt influenced by my typewriter-oriented background, where 5-letter words and 200-word pages were the established standards.
In general, clients accepted this precept. As our clientele began to change from one-shot end-user jobs to more complex multi-language jobs from printers or other middlemen, however, we began running into problems. For example:
"I sent two pages of Japanese. Why is the invoice for 10 pages of English?"
"You only delivered two pages of English. Why is the invoice for 4 pages?"
"Why is the same source text invoiced at 15 pages in English and Korean and only 12 pages in Chinese?"
"Your estimate was for 12 pages, but the actual translation only looks like about 10 pages."
"Sorry, you estimated 10 pages. We can't pay for 12."
There are a few problems involved here.
The first problem is that most customers don't understand the difference between a sheet of paper and a billed "page" unit of work. We defined a "page" as 200 words (Roman-character languages) or 400 characters (CJK languages), and were in effect billing by the character count, regardless of how many characters were on a sheet of paper.
The second problem is that since we were billing by the output character count, more efficient Chinese, for example, was able to pack the same amount of information into fewer "pages," causing a price difference.
And the last problem is estimates, potentially the most damaging of all. Since we were estimating the output character count from a known source count, there was of course error. And to assure our own profit, we automatically padded estimates on the safe side, of course. No matter which way the error turns out, the customer is either paying too much or too little, and eventually someone will notice and get upset.
The problem of not being able to accurately estimate the fees for a job can have a number of effects. It can result in the loss of a job or client (if your estimate was too high and thus unacceptable), the loss of deserved income (if your estimate was too low), and the loss of your cool (if there are even minute differences between the estimate and the output). Results like these are not good.
In addition, output-based estimates require that the entire document be received before the estimate can be issued when a customer wants an estimate because, for example, a legal contract results in a greater number of output English words than a tourist brochure. This process meant that clients had to wait to receive estimates, which is often a major problem when dealing with printing and production companies.
If invoicing is based on the source text, an accurate estimate is theoretically possible with just the source character count (I say theoretically because we have all experienced jobs that turned out to be written in crayon on paper towels, with a client demanding that we deliver by tomorrow morning as per our estimate...). If the customer knows our fee per 400 characters of Japanese, they can estimate it themselves and arrive not only at a close guess, but probably the exact figure.
Source-based methods can be less efficient at times, however. For clients who don't need estimates and who can be billed by output volume, a simple word count of the finished job gives you the invoice total. Quick and simple. Under a source-based system, EVERY job must be counted in the source language. If you are lucky enough to receive source documents electronically, that's fine, but you are probably like the rest of us, with a host of faxes or laid-out documents that cannot be counted automatically (with bitmaps, embedded objects, or even Word text boxes).
In the process of introducing a new estimating and invoicing system, however, we had to be careful to not raise the cost of a given job (well, not visibly, at any rate...). Since we were already using various methods of calculation to convert Japanese character counts into output English word counts, or whatever, converting the other way was simple enough to be able to come up with a very close number. We did that, and drew up a price list accordingly.
As we were reviewing the price list, though, we noticed a few problems. First, we still charged by the "page," and from past bitter experience I know someone would confuse that with a sheet of paper, no matter how many explanations I included elsewhere. The first thing we did was to remove all mention of "page" from the pricing for translation. Under design and layout, we listed things by "sheet," "file," "table," or "illustration."
The second problem we noticed was the increment. We have always counted 200 words or 400 characters as a "billing unit," counting in half-units. This strategy seemed reasonable at the time, but pretty silly in retrospect. We remedied this problem by changing the "billing units" to 100 words and 200 characters, rounded up. There were no more "half-units" to worry about, and the price list was simplified considerably. Changes meant recalculating all the prices again, but computers are pretty good at crunching numbers.
We mailed out a Dear John letter on May 15th, describing what we were doing, and announced that the change would go into effect on June 1st. We stressed the fact that effective costs would not change and enclosed the new price list.
As of March 13th, we have yet to hear a complaint. In fact, we have gotten essentially no feedback at all. For customers who send us something we can accurately estimate, we count the source characters and produce an estimate and invoice on that basis. For customers with those seemingly endless jobs consisting of floods of faxes and materials sent via express mail, we keep track of output characters and bill accordingly. While the prices produced by source count are very close to the prices produced by output count, nobody has asked about the difference or seemed to care. They appear to be looking only at the bottom line.
The number of complaints and invoice queries has dropped. The number of incorrect estimates has plunged to almost zero. Overall, I would say that the change was a beneficial one in every respect, and I am thankful that it went as smoothly as it did.
Feel free to address any queries to me directly.
Source: JAT website. March 13, 2002