Re: [hylafax-users] routing received faxes to clients

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.07.06 10:29 Bill Binko wrote:
> Lee,
>
>   You are (as usual) right about DID being the best way to do this.
> However, I have tried to make that sale to a small business client,
> and
> it's a high hurdle.  In many cases, it involves switching at least
> phone
> plans, and in his case phone companies.  It simply wasn't worth the
> effort.

I've investigated analog DID services for clients between three 
different telcos.  All three of the telcos (Qwest, Sprint, Pacific 
Lightnet) offered analog DID service at around $40-50 per month per 
trunk/line.  Pricing on "blocks" of DID numbers varied significantly 
(between $5-20 per month per 20), but not enough to make it notably 
expensive.  The MT5634ZBA-DID modem is roughly $400, and one is used 
for each line/trunk.  So that's the "expensive" part of it, but it's 
certainly less than purchasing a new multiport modem, and it's far less 
than moving the client from analog to digital systems and having them 
purchase digital equipment.  (Of course, once you talk about more than 
about 4-5 lines/trunks, then digital becomes the more economic 
solution.)

So, basically for an initial investment of $500 and a monthly recurring 
fee of less than $100 you can accomplish a very attractive solution: 
routing faxes solely based on the number that the sender dialed.  The 
sender can be trusted to do that, because they can dial a number 
already as a minimum expectation.

Now, certainly there are "cheaper" solutions to this; OCR and 
subaddressing are a couple of these.  However, except for the case 
where the routing needs to be virtually dynamic (i.e., the routes are 
not static), or there are an enormous amount (i.e. several hundred) of 
routing possibilities, I can't think of a situation where any solution 
is going to be better for the users than DID.  The problem with 
subaddressing is that many fax machines can't send subaddresses, and 
even then it may be difficult to educate those who send you faxes on 
how to use subaddressing.  So, really, unless you can control both the 
sender and receiver yourself, it's very difficult to make subaddressing 
work ideally.  Now, I've never used OCR, but it would seem to me that 
the problem with OCR-based routing would be tightly tied with the 
limitations of OCR.  (I.e., let's say the sender doesn't have ECM on 
their fax machine, and the bar code/key routing text on the page gets 
garbled, but not enough to trigger RTN... then your receiver will 
respond with an MCF confirmation, and how does the fax then get 
routed?  Or lets say the sender fed the page in crooked... can the OCR 
software decode a crooked barcode?)

I'm not trying to say that everyone is wrong for trying to do things 
economically.  I'm not saying that there isn't a place for non-DID 
routing mechanisms.  What I am saying is that I suspect that nine of 
ten inbound routing mechanism needs can be satisfied best with DID, and 
the investment in it will be well-made.

>   I hope I don't move this off-topic, but right now, we're primarily
> concerned with routing faxed-in applications.  These are on our
> standard
> forms, and it is very possible for us to "force"  them to send in apps
> on
> our forms (we already do for regulatory reasons).

But this doesn't necessarily guarantee that the faxes you receive will 
be legible by the OCR program - while they still will probably be 
legible to a human.  That human can be the sender.

>   I have floated the idea of barcoding through my customer, and they
> love
> the idea.  However, after searching the archive, I have found little
> help
> (Basically, one guy said he found a $50 solution.... but didn't post
> it
> :(  ).
>
>   Lee, do you have any experience with this?

I don't have any use-experience with received-fax barcode scanning or 
received-fax OCR.

There seems to be plenty of potential, if that's what you've not been 
able to find:

http://jocr.sourceforge.net/
http://barcode.sourceforge.net/

> I know you have settled
> on
> DID for your current application, but perhaps you have a trail you've
> given up on that I could pick up?

Well, technically it wasn't *my* application, but my clients' 
applications, but yes, I found DID (or a multi-line/modem installation) 
to be a better fit.

> (It would be VERY nice to route
> inbound
> apps to the processor for the right state.  I know that sounds minor,
> but
> it really isn't in this case.)

50 states = 50 DIDs.  ;-)

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*