[hylafax-users] DID vs. OCR/Barcode Was: routing received faxes to clients

[Bill Binko <bill-sender-4b2fd6@xxxxxxxxx>]

On Tue, 6 Jul 2004, Lee Howard wrote:
...
> 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.

Actually, it came out quite a bit higher than that.  He currently has a
three line hunt group that feeds into three multitech modems in a server
that also hosts his email, database, etc.  (The additional load on the
server is essentially zero cost at this point.)

Using your numbers, to replicate that would add $400 per line for the new
modems, plus a recurring cost of $50 per line for the DID capabilities
plus $20ish for the block.  So it would be about $3500 the first year plus
~$2k each year after that.

The reality (in his case) is that he's using a T1 split for voice and
data.  When he tried to get a price on the DID, they said they'd have to
add DID to all the voice/fax channels on the T1 (12 lines).  Now, that may
be a marketing ploy, but it increases the cost considerably.

The other issue is that he doesn't NEED some of the benefits of DID. Sure
some of his people would like a dedicated fax number, and it would
certainly make it easier if it just emailed it to them after the DID was
detected.

But the real reason he wants routing is to route based on content, not
destination.  Here's the two main scenarios:

First, there's new business:

1) A user decides they don't want to apply online and downloads a PDF form
to fill out.  Ideally, they fill out the form using the PDF forms support,
but lots of time, they fill them out by hand.

2) The form has an identifier on it that says which form it is (about 20
forms map to the 50 states).  That id could be in a barcode form.

3) The potential customer faxes it to an 800 number that feeds the 3-line
fax hunt group.

4) Those applications need to be routed to the people who handle new
business.  Ideally, they'd be broken out by form or state since the people
are distributed geographically.

Right now, that sorting is done by a single resource who does it twice a
day.  If you send that fax at 9:35am, there's a good chance noone will
look at it until the following day.  That day costs him a great deal of
business.  He's tweaking the scheduling, but it's a pain, and it's a
management issue to be watching that.

The second scenario is a bit more subtle: its about losing information.

When he sends out letters through the fax server, we scan the PS files for
the customer number and attach a PDF of the sent fax his customer in his
database.  (I'm looking forward to using the built-in support for some of
this in 4.2.0 :)

When a customer faxes back a response (Usually after simply signing the
document that was sent out), there's no way to match it to the original,
or to automatically attach a PDF of the INBOUND fax to the customer.

Embedding a barcode on the sheet they needed to sign might help this.

> ...  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've seen some good barcode detection (albeit from Cardiff -- a pricey
software vendor if there ever was one) that could certainly detect a 128B
barcode even at fax resolutions (and with a skew).  That doesn't mean the
open-source alternatives are anywhere near there... but it's not
impossible.

Also, if even 80% got routed correctly, it would help the new-business
case considerably.  Others could be hand-routed.

>
> 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 know, and it certainly is the most fool-proof solution if it fits!  I'm
just having a hard time shoe-horning it into this particular application
(perhaps I'm in that 10% :).

> There seems to be plenty of potential, if that's what you've not been
> able to find:
>
> http://jocr.sourceforge.net/

This is where I think there's the most potential.  GOCR is fairly stable
and well-deployed.  Now that they have barcode support, perhaps there's a
solution buried in there.

> http://barcode.sourceforge.net/

This seems to be an invenvtory system using barcode scanners.

Anyway, I'll make sure that if I find a solution, I'll post it back.

Thanks for the thoughts,

Bill


____________________ 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*