I wrote an unusually abrupt post a year or so ago about PostalMethods a service that automates the sending of postal mail. At the time I merely looks at part of the offering and my doubt was expressed in no uncertain terms by saying;
WTF? Postal Methods connects to the business via API to output documents – isn’t this fancy words for “we have a printer”? I mean I know that outsourced mailing companies exist but giving this a Web 2.0 moniker and getting all fancy schmancy talking about APIs – isn’t that gilding the lily just a little?
David from PostalMethods good naturedly responded saying;
Yes, we have a printer. After we print customers’ documents, we neatly fold each page to three, insert it carefully into the right envelope, lick the glue and close it, lick the stamp and make sure it sticks to the envelope and quickly run to the post office. (That was a joke by the way – we use fast machines).
Always gluttons for punishment (or perhaps hopeful that I’ve softened in the past year) they contacted me recently and invited me to take another look at what they’re offering. Ido from PostalMethods was quick to point out the business automation aspects of what they’re doing rather than just the simple outsourcing ones.
To recap, PostalMethods allows users to send physical mail from such applications as Word 2007 Mail Merge, Xero, Simply Accounting by Sage, SAP R/3, Zoho Invoice, MS Dynamics CRM, all without actually using a printer, an envelope or a stamp. PostalMethods catch cry is that they’re “making sending letters as easy as sending automated emails – No more manual printing, folding, inserting, sealing, stamping, or delivering. PostalMethods does it all for you”.
PostalMethods also enables other software vendors to onsell their product – their Partnership options allows other vendors to use PostalMethods as a kind of an OEM service so they offer their customers the ability to send postal letters directly from their product and charge them directly. End users do not need to know about PostalMethods – the vendors gain a new revenue stream and leverage their aggregate customer base to attain volume discounts.
So over the past year I have to say I’ve softened my view of the PostalMethods offering. While my core belief is that truly connected applications will greatly reduce the necessity for physical letters to be used, the fact is that this vision is a long time off – until then we’ll continue to *enjoy* bits of paper piling up on our desks.
Ido got all excited describing a use case for me;
From impossible to possible: say you have an e-commerce service and some of your customers require an invoice by mail (mostly common with government offices). It’s impossible for a small business to send dozens of letters a week. You’ll need to have an employee to do just that. With PostalMethods, you’ll just need to write some code so that an invoice is produced automatically, immediately when your customer is making a purchase and requests an invoice by mail. You can even charge them $2 for it and make a $1 profit…
As I said previously, my questions around PostalMethods related to its utility as a pure outsourcing arrangement, however from a business process automation perspective it makes sense. One of my businesses does a monthly statement run that take a person considerable time to print, fold, envelope and stamp – PostalMethods would save this time…
But therein lies the rub. Sure PostalMethods may save time and money by automating a physical service, but it’s still replacing a physical service with an automated and outsourced physical one. Taking a step back and looking at it holistically, how many of those physical letters really need to be sent at all, how many could be replaced by electronic invoices at the least, if not full-blown application integration that would allow data transfer between entities and between applications.
So yeah, I get PostalMethods more than I did previously… but I still wish there was no need for it.
