Feed Powered Auto-Responders

A few weeks ago, I got my first “real” mobile phone, an HTC Magic (don’t ask; suffice to say, I wish I’d got an iPhone:-( and as part of the follow up service from the broker (phones4U – I said I might be tempted to recommend them, so I am) I got a ‘will you take part in a short customer satisfaction survey’ type text message.

So when I responded (by text) I immediately got the next message in the sequence back as a response.

That is, the SMS I sent back was caught and handled by an auto-responder, that parsed my response, and automatically replied with an appropriate return message.

Auto-responders are widely used in email marketing and instant messaging environments, of course, and as well as acting in a direct response mode, can also be used to schedule the delivery of outgoing messages either according to a fixed calendar schedule (a bulk email to all subscribers on the first of the month, for example) or according to a more personalised, relative time schedule.

So for example, a day or two after getting my new phone, Vodafone started sending me texts about how to use my phone on their network*, presumably according to a schedule that was initiated when I registered the phone for the first time on the network; and the Phones4U courtesy chase up was presumably also triggered according to some preset schedule.

* something sucks here, somewhere: I keep finding my phone has connected to other, rival networks, and as such seems to spend large amounts of its time roaming, even when in a Vodafone signal area. Flanders – you owe me for making such a crappy recommendation… and Kelly, you have something to answer for, too…

So, these auto-scheduled, auto-responding systems are exactly the same idea as daily feeds: whenever you subscribe, a clock starts ticking and content is delivered to you according to a predefined schedule via that same channel.

In a true autoresponder, of course, the next mailing in a predefined sequence is sent in response to some sort of receipt from the recipient, rather than a relative time schedule, and in the case of autoresponding feeds this can be supported too if the feed scheduler supports unique identifiers for each subscription.

(The simplest daily feed system has a subscription URL that contains the start date; content is then delivered according to a relative time schedule that starts on the date contained in the subscription URL. A more elaborate syndication platform would use a unique identifier in the subscription URL, and the content delivery schedule is then tied to the current state of the schedule associated with that unique identifier.)

So how might a feed autoresponder work? How about in the same way as a feed stats package such as Feedburner? These measure ‘reach’ by inserting a small image at the very end of each feed item that is loaded whenever the feed item is viewed. By tracking how many images are served, it’s possible to get an idea of how many times the feed item was viewed.

The same mechanism can be used as part of a feed auto-responder system: for a subscription via a URI that contains a unique identifier, serve an image with a unique, obfuscated (impossible to guess at, and robots excluded) filename for each item. When the image is polled from a browser client, assume that the subscriber has read that item and publish the next item to the feed after a short delay. The next time the user visits their feedreader, the next item should be there waiting for them.

PS Note that someone somewhere has probably patented this, although as a mechanism it’s been around and blogged about for years (prior art doesn’t seem to be respected much in the world of software patents…) If you have a reference, please provide a link to it in the comments to this post.