Deliver / fetch...“You say potato – I say potato”???
Let’s go back to the trusty old dictionary:
Deliver: to carry and turn over (letters, goods, etc.) to the intended recipient(s).
Fetch: to go and bring back; return with, get.
The key part of the definition of deliver(y) is that the recipient receives something 'in hand' at the end of the process. So in the context of eDelivery, the recipient should receive the actual document 'in hand' - just via electronic means.
Most companies' eDelivery programs are not aligned with the definition of ’deliver’. Instead, their solutions require the customer to go to a website and fetch the document.
There are some folks who say that delivering the document to the website is eDelivery. They’d argue that I’m just discussing semantics.
But the whole concept of eDelivery is sending the document to the customer. Just like an envelope would be sent to a mailbox, the company should deliver documents into the electronic equivalent: the email inbox. Email is the vehicle to really achieve eDelivery.
Email: the most compelling eDelivery option
It ticks all the boxes:
It feeds off existing customer preferences – have a look at Mike Wright’s recent blog post about a Harvard study that indicates nearly ¾ of internet customers use email for eDocument delivery. People don’t prefer file sharing sites, online PO boxes, or online document storage.
It is the easiest online tool for sending and receiving documents. What better way to deliver a customer’s eBill, eStatement, ePolicy, or eDocument than as an encrypted PDF attachment to a personalized email?
It is device agnostic and comes as a standard install on all smartphones.
And finally, it’s already part of our daily lives.
Delivery of secure PDF documents into the email inbox mimics the mail world and keeps the concept of delivery alive.