faxman

I'm working on PayPerFax - https://payperfax.com/ - a simple online faxing service that lets individuals send faxes without committing to subscriptions or creating accounts.

The idea came from an interesting "tail wagging the dog" situation. I had an old domain (faxbeep.com) lying around unused which I'd been renewing for 20 years. When I finally built something there, I discovered users were more interested in a fax testing feature that I'd added as an afterthought - the abitlity to send a fax to our test numbers and see it appear on the website for 30 days.

That insight led me to dedicate faxbeep.com entirely to fax testing, and to buy payperfax.com for my original idea: straightforward, pay-as-you-go faxing. People still need to send faxes surprisingly often - for tax authorities, immigration paperwork, medical prescriptions, etc. The service charges a fixed fee for a 3-page fax (cover + 2 pages) with a bit more for additional pages, and you only pay if the fax sends successfully.

My current challenge is visibility - Google has essentially black-holed the site. Even exact match searches like [pay per fax] don't bring up the site. If anyone has SEO advice on how to climb out of this hole - I'd appreciate it!

True, but then, taken to its logical conclusion, isn't everything just "things that emerge in an observer's model of the world", e.g., an ant, a chair, a rock?

Healthcare providers have been entrusting their faxing to outside service providers for quite a while now, without on-premise installations.

InterFAX is the SaaS version of RightFax. No installation of hardware, software, or phone lines required. (But, as with any Saas, trust in the vendor is necessary).

Any reasonable fax service provider will allow reception of multiple faxes concurrently. Some might deliberately limit the number of concurrent connections so that one client's activity doesn't kill their other clients, but even that sort of throttling would in practice be a very rare event.

Your description is right. To give this a visual dimension, here are sequence diagrams showing how outbound and inbound faxing work at another provider (disclaimer: I'm a co-founder at Interfax):

Outbound: https://www.interfax.net/en/dev/dev-guide/using-interfax-for...

Inbound: https://www.interfax.net/en/dev/dev-guide/using-interfax-for...

Your suggestion for a "sign this and send it back" workflow is an excellent idea. Indeed it shouldn't require more than a single fax number per client, leaving the barcode to do any necessary association. But I would say that this functionality is not best placed on the fax service provider's system, but rather in the application that creates the document to be signed and eventually receives it back. Here's what I mean: http://imgur.com/a/JEldx

You might want to take a look our service, Interfax, an API-powered internet fax service provider, which addresses HIPAA and offers BAA's.

In fact, we cover a range of regulatory/standard requirements such as PCI-DSS (Tier 1) and EU GDPR.

We're now also looking at the Oz equivalent of these types of legislation.

https://www.interfax.net/en/hipaa_compliance

> only maintain libraries for your SOAP endpoint (at least for now

Check. This was the decision that came out of today's product meeting after reading responses here.

> Put up a form...

Check. Already did this a couple weeks ago at www.interfax.net/en/dev/rest. Already got a few bites.

> Just because someone on a survey said they wanted REST instead of SOAP ...

I agree. However, we ran several variations of the survey including one where developers had an opportunity to say that not having REST is a show-stopper for them, which got us worried.

Strangely, most of those who insisted on REST develop in environments which have the strongest SOAP support, like C#, PHP, and Java. This got me thinking that we might be dealing with fashion issues more than practical issues...

> ... conditioned to vote for REST over SOAP.

Yes, I dread to think I'm going through a lengthy project just to address a current fashion trend...

> If you're always providing API access through a proprietary library, > it doesn't matter if it's REST, SOAP, custom binary protocols, or whatnot.

That was exactly my thought. I was looking for reinforcement of the possibility that people will still want the entire REST interface visible and documented even in the presence of wrapper libraries.

OK, thanks. Going back to the drawing board with renewed vigor!

Actually, moving to REST requires you to change your head around from a procedural point of view to one dealing in objects and operations, so it won't be a direct mapping of SOAP to REST.

No, not trolling.

The vast majority of API providers do provide libraries (of course, none of them "force" you to use them, and nor will we), and this is considered good practice in many places (see for example the recent "Designing Great API Docs" at https://news.ycombinator.com/item?id=3453315).

I understand the purism of doing it the REST way, but if in practice most developers end up using a library which abstracts away REST - that's what prompted my original question.

This is definitely interesting - "printing" the active document, selecting the recipient from an address book, then selecting the job type is a very natural work flow. I'll definitely research the availability of printer driver SDK's that can reduce implementation complexity.

Thanks!

Wow, that's a lot of material to digest, thanks!

Let me start at the end - the idea isn't actually original. I remember Compuserve offering a similar service around the late 80's! I agree this all succeeds or fails based on execution.

> ... make sure you're doing address cleansing for the extra postage discounts.

Yes, this is actually addressed in our FAQ - we do address validation.

> Make a utility print driver so I can "Print To Postal Shout" -- this is VERY easy to do, at least on windows...

Could you please elaborate on this? I was always under the impression that building print drivers was a very expensive undertaking.

> ...Upon completion, create an XML doc (or similar) and call a web service ...

We actually do this now with our Word add-in which makes it easy to submit letters to distribution lists. Instead of running a mail merge in Word, the document and list are uploaded via Web Service.

> ...If you could somehow incorporate electronic signature / notary / SOMETHING into the documents...

This is very forward-looking at this stage of our project. I'll keep this in mind for later.

> Offer stationary / letterhead for the customers to design and use...

Great idea! With digital printing it's possible to print letterhead on the fly.

> You could offer discounts on the actual costs if the user was willing to have ads printed...

We haven't been successful in generating additional sales from similar initiatives in the past. I'll need to revisit this option.

> target Salesforce.com...

We do this with our postalmethods product, but haven't been diligent enough in execution. Will need to put more energy into this.

Thanks for all the suggestions! It would be great if you could clarify on the printer driver question above.

> That info isn't "above the fold". Stuff like: "Start now with as little as $10!" "From only 75c per letter...

Thanks, excellent point!

> No autoplay on the video with audio

We tried several approaches with video, and unfortunately no one ever clicked 'play'. Since the entire motivation for the service is given in that video we really wanted it to be seen. I was worried about getting your kind of feedback, so I guess we'll have to rethink this.

> I should understand exactly what the site does without having to watch the video

This feeds into what's discussed above.

Thanks!

Zowie, that was fast! Thanks, the logo is indeed being looked into to make it stand out more on the page.