Solving e-delivery: fundamental requirements

This is part three of a series on e-delivery: <%- partial_page(‘_partials/edelivery-index.html’) %>

You are a bank, biller, health care provider, insurer, payroll or other businesses. You currently do not have a way to push confidential documents and messages to end users and to notify your customers (users) of new content or messages.

How do you send messages and documents to the user, and make them aware that they have new content? For a message solution to work you need to make notifications available to the user in a place that your customer frequents. You don’t send the actual message or document via email because of security and reliability issues. Instead you are putting the message or document on your own web site and, for important content, sending users an e-pickup notice via email. But content is only retrieved when users get around to it, which in many cases never happens.

An aggregation app with consumer-driven design

ll be sure to open it more then once.

What could be a better approach to sending users messages and documents? Is there a way to send the actual content _to_ users so you don’t need to send a separate e-pickup notice? A solution would ideally put new content where consumers want this content, which is on the device they are using. And notifications will also be available where the user will see them. One way of doing this is to write your own native app and deliver content via this app. The app could retreive and store files locally and hook into your device’s notification system. But it’s difficult to get users to download your app, and downloading apps becomes a burden to users if you consider that users have upwards of 20 business relationships from which to get notifications. Not to mention that developing custom apps is expensive.

How about a generic app that can aggregate content from multiple businesses? This could be a web or native app. If a web app you have to rely on the user finding enough utility in the app to want to use it in the first place, the user visiting the web app with adequate frequency, and both you and your customer trusting the web app with credentials and sensitive content from 20+ businesses. A web app won’t work if it is ever important that your customers receive immediate notification of new content, unless your customer keeps their web app open all the time.

What if the aggregation app is a desktop or mobile (native) app? This would allow the app to be always on and hook into whatever the OS platforms notifications mechanism is. It would also allow you to deliver documents to where most users want them delivered, which is _to_ them, and for users to maintain control of their documents and decide on their own backup strategy.

Your solution needs consumer-driven design, at least to the extend that you convince consumers to use what you have to offer. What are your customer’s needs? For the consumer to want to participate, they must see value and not be frustrated by your offering. iTunes streamlines the music and podcast download process and keeps your media organized: your solution should help your customer do the same for financial records. Should the solution also help your customer with backup and accessing and/or synchronizing their content across devices? Would hooks to allow them to share certain records with their accountant or spouse be helpful? What about paying bills and other related money transactions?

Could the browser manufacturers build in the notification and delivery hooks that you need? This might be interesting, but it’s currently not on the horizon.


How would you build the bridge between your business and the aggregation app? This is an issue to resolve regardless of whether the app is desktop, web or a browser. Do you have _N_ different web app solutions each proposing their own onboarding API? What if the solution is a desktop app or a browser? These cannot have APIs to which content can be pushed. The protocol solution must therefore be a feed API along the conceptual lines of RSS or atom feeds where the app contacts your servers to retrieve customer information. This would allow any approved app to access your data.

What content should the feed protocol handle? This is your channel for communicating with your customers, so you may want it to be reasonably rich. At a minimum it should handle basic email-like messages. 140-character alerts make sense as well. We would need to include documents such as statements and tax documents that also need to be pushed to users. What about targeted microblog information from your company, or promotions, or URLs for web site access and support? Depending on the agent that is connecting to your feed, the specific agent may or may not be able to handle each of these different feed data types, or end-points as I prefer to call them.

How do you authenticate the agent connecting to your data feed? You want to both authenticate the user and possibly the agent as well. The user should be authenticated using a token system such as OAuth 2.0 so that the user does not need to expose web credentials to the agent. Authenticating the agent application itself could be just as simple, but if the agent is a client application it becomes more difficult for the client app to protect the tokens from being stolen from binary code. You can either accept this situation or look for DRM-like protection of client keys. This is where authentication gets a bit more complicated and you start having to look for experienced, outside help to activate client apps and provide a mechanism by which client app tokens are authenticated.