According to Slashdot:
Amazon.com has a new program that wants you to 'Complete simple tasks that people do better than computers. And, get paid for it.' (example: 'Is there a pizza parlour in this photograph?'). For each task you complete you get a small payment, usually ranging from a few cents to a little under a dollar. It's named the Amazon Mechanical Turk after a famous hoax from the 19th century. Kill time and get paid in tiny increments to boot!
As if to prove there's nothing new under the Web, here's my prior art from 2000, when I worked at Oracle. (Note: this was done in my own time, and isn't Oracle intellectual property. But I did pitch it to Oracle as an idea.) What's interesting from a telco perspective is their failure to further develop the payments and small transactions side of their business. They should be in a great position to broker small payments between network users. The mobile operators are starting to make a go of it, with some success using kludges like reverse SMS. The landline operators haven't really tried. (As usual, micropayments got caught up in a "content is king" miscalculation as payment for media, rather than focusing on user-to-user payments.) Perhaps if the billing platforms had been just a bit more open, things would be different?
Interestingly, Paypal has become the "banking parasite" equivalent of the VoIP parasites like Vonage. To operate fully Paypal requires you to back up your identity with existing banking products like a checking/current account and credit card. The banks pick up the expensive sales, marketing, credit control, operations and fraud costs of these products. By making two small random deposits into your account, Paypal gets to suck out some custmer data -- the association of a person and account. They can be assured of its authenticity, all without having to make a business development deal with a bank anywhere. My bank now doesn't allow automated establishment of direct debits (I have to fill in a hand-written form), which helps them to stymie companies like Paypal leaching off their business model. The banking equivalent of port blocking! Funnily enough, telcos have credit-checked customers whose real addresses are known. But that information hasn't been capitalised upon in any horizontal business model extensions.
Anyhow, back to the main story. As a follow-up, I wrote:
The attached typemein.com proposal is really part of a bigger picture. What I've proposed - snippet data entry - grabs one of the lower hanging fruit on a big tree. In the longer run, what I'd like to create is a form of exchange for unskilled and semi-skilled on-line labour.
Hopefully that's an Amazon patent application poisoned with a bit of prior art.
So, from historical interest, here's the lightly edited version of my original paper. Read, and weep about another missed telco opportunity. Warning: Long, laboured, and only marginally on-topic.
Let’s say you work for a well-established bank, running their cheque processing centre in Stockholm. Your 100 data entry clerks cost a fortune in pay and overtime. But what can you do to reduce costs?
Now imagine you’re a student in Lithuania, just across the Baltic. It’s hard to make ends meet, and you only get paid $1 an hour working as an office cleaner in the evening. If only you could find a better-paid job that allowed you to work at more convenient hours.
This business proposal shows how we can supply the Lithuanian student to work for the Swedish banker, and make a profit from the global differences in prices for unskilled labour.
We first describe a particular application of these ideas in depth. All of the relevant features of the idea are covered by this one example. At the end of the document are suggestions of ways in which the business model could be extended to cover other business applications.
There is a galaxy of big enterprises involved in processing paper-based documents: not just banks sorting millions of cheques each day, but also insurance companies receiving van-loads of claim forms, and governments issuing tax forms to businesses and individuals. Whole industries are based on processing these documents: data entry, remittance handling, workflow, fraud detection etc. This business proposition focuses initially on the data entry segment. In particular, we will focus on those documents which are time-sensitive (e.g. cheque clearing) or where demand is highly variable or short-lived (e.g. share IPO application forms).
Traditionally these documents were physically moved from office to office to have the data entered. In the last decade this has changed to image-based solutions, where documents are scanned and the images are stored on a central computer system and displayed on PCs for data entry. I propose to publish these images on the World Wide Web to enable lower-cost workers to enter the data, based on a variable piece rate. We will create the world's first marketplace for direct on-line work. This is a totally novel business model. Indeed, it fails to fit into any of the conventional categories of e-commerce. It involves the creation of an entirely new industry.
Until now remote data entry was not technically or economically possible. The telecommunications infrastructure was too slow and expensive; deployment of powerful networked computers was too thin; the need to remotely install complex PC applications too onerous. In the last 1-2 years this has changed; cheap PCs are fast enough to do high-speed data entry via a browser, and Internet access is becoming cheap and widely available—even in less developed economies. Even better, there are target groups like students who can provide a ready-made workforce available with exactly the right ingredients: wired, needing money and with time to spare.
The business will make money by charging a higher rate to those who need data keyed in than is paid to people doing data entry.
Clerical workers in Western countries occupy expensive offices and are paid Western wages. Their salaries are padded with generous benefits such as sick pay, pensions, and paid leave. They are often heavily unionised, and sometimes strike-prone. Some countries have heavy-handed employment regulation; for example in Norway it is (amazingly) not permitted to measure the individual productivity of data entry workers. Moving to an overhead-free environment with a frictionless labour market leaves a vast price gap from which to make money. The differences really are enormous: Sweden’s per capita GNP is approx. US$20000, compared to US$2000 a few hundred miles away in the Baltic states.
The proposed business has significant barriers to entry once established (see below for more details). Combined with the arbitrage of such extreme price differences, the potential for profit is considerable.
For the purposes of this document we shall refer to the enterprises that have data entered on their behalf as our clients; after all, they provide the revenue. Those who perform the data entry are the subscribers. Our employees are those who work directly for us in sales, marketing, technical functions, etc. We now discuss in more detail exactly what is being proposed.
Anyone with a high-volume business of documents to process. We aren’t targeting those who want a few pages of a thesis typed in. Typical clients would include banks, insurance companies, utilities and government agencies.
Some types of client may have very specialised requirements. For example, the postal system will need postcode data entered, and will have a huge peak in volume before Christmas; but all data must occur within 5 seconds of scanning whilst the envelope is still in the machine and awaits sorting. The system may require tailoring to each customer’s requirements as a broader range of clients is addressed.
Initially we’re focusing on machine-printed or hand-written data. In particular, we are looking for data suitable for snippet keying. This is where individual fields can be cut out from the overall image. This data is either positioned within predictable boundaries on a document (e.g. your date of birth on a standard application form), or can be located on the document using image processing (e.g. looking for the address on an envelope, or the pound sign on the amount field on a cheque). Long reams of text to enter are not particularly suitable, although one could conceive of breaking these up into line-at-a-time units.
This use of snippet keying is critical to the exercise. Most importantly, by extracting data from its context, it becomes safe to display it publicly. We never display the whole document except to the client’s own staff. It also chops the data into standardised pieces, and avoids people having to type in whole documents, where the temptation is to skip hard ones by logging out and trying again for an easier one.
We will have to integrate with the imaging systems already in place at the client’s processing centre. Sometimes they may specifically install an image-based system to be able to take advantage of our service. The rules for locating the fields can sometimes be complex (e.g. cheque sizes and field positioning vary significantly); in this case we may need extensive integration with the client’s legacy systems to extract these rules.
When a subscriber logs in, they will be presented with a number of different data entry tasks available, and an indicative price per item entered. They choose the task they want to do. Some people may prefer high-speed numeric keying, others names and addresses. They then key in data; when they want to stop, they can. Certain types of data may have very simple entry rules (“just type in each 2 digit number”); others slightly more involved.
Some data (like account numbers) will have a check-digit that verifies no keying errors have been made. Other fields (e.g. a bank sort code) can be checked against a standard list. Some can only be checked in combination (e.g. “cheques with transaction type 10 can only be for business accounts”).
No validation is done at the time the data is typed in; instead, this is done at the back-end, with items that fail to validate being sent out for re-keying. This keeps the data entry application as simple as possible.
Certain types of data are very important that they be entered precisely. Examples include the number of shares applied for, or the amount on a cheque. There may be no way of validating the amount entered directly. In these cases the data will be keyed in twice by different subscribers and the values compared to check they are the same.
There are some important advantages to the business model proposed above:
Particularly critical are the high barriers to entry to any future competitors:
A unique business model is nice, but it doesn’t pay the bills. Where will the revenue come from?
Unlike too many Internet ventures, this proposal has a clear revenue source from the outset, namely the difference in price between that charged to the client, and that paid to the subscriber. Furthermore, unlike many Internet-based business models, this does not have huge sunk mass marketing and infrastructure costs incurred prior to revenues appearing. We only spend money on integration and subscriber acquisition once we have a contract with a client.
It is possible that at times the service will be run at a loss to ensure sufficient subscribers to cover peak demand, or to encourage new subscribers. Established techniques for forecasting and managing pricing and supply, for example as used in the airline industry, will be used to ensure we make a profit over the longer term.
There are ways of trying to squeeze extra revenue from subscribers by marketing other services or advertising to them. However, we have to remember that these people are unlikely to be the prized cash-rich/time-poor customers normally sought after by B2C enterprises. Therefore unless there is compelling evidence to the contrary, the business model should not be muddied by such additions.
Potential partners include the following:
Some of these could also be potential competitors, so care will be required.
Clearly there are two completely separate audiences to market to: the clients and the subscribers. The former will be large (and potentially conservative) organisations that will need to work with experienced sales personnel. Traditional means of advertising in industry journals and general business publications are most appropriate.
Marketing the service to subscribers is a much more interesting challenge; uniquely, you are offering the opportunity to earn significant amounts of money rather than spend it. The marketing strategy is likely to centre on direct means of contact with potential subscribers (e.g. students, existing data entry clerks). This could mean standing outside the gates of college lecture halls handing out marketing material. Generating interest from subscribers is also a text-book candidate for viral marketing techniques.
Given the unique business model, generating headlines in the media should be less of a challenge than for those with more conventional B2C or B2B offerings.
There are a number of different ways that the business could be developed. These include:
So, does it all sound too good to be true? Where’s the catch? Well, here are some potential objections—and some corresponding solutions.
Conservatism. It’s all just too far out for staid banks and governments.
When the Royal Bank of Scotland takes over NatWest and promise hundreds of millions of pounds in savings, are they going to turn you away when you can save them a few million a year? In today’s competitive world, this is a luxury few could afford.
Data quality. Surely you could type in any old rubbish and get paid for it?
Not in this game! New subscribers would be fed images that have already been keyed. The accuracy of their work can then be gauged. Those that consistently under-perform will have their subscription terminated. Others will get paid a lower rate to reflect their lower quality. The longer someone subscribes, and the better the quality of their work, the fewer of the images they key in will be double-typed. Quality control will be an integral part of the operation.
Penetration of image technology. You rely on the forms being imaged. Not everyone has this technology.
There is no reason to wait for ubiquity of image-based processing to proceed. Furthermore, the success of the remote data entry business will ensure that those that do not have it will be at a significant cost disadvantage compared to those that do.
Security and data protection. No bank is going to let the world see its customers’ private data. I’d be horrified if anyone saw my health insurance claim.
Well, if you’re rich and famous then you can be sure someone at BUPA’s processing unit will already know all about your embarrassing medical condition. In fact, this is more secure since we only publish snippets of images out of their original context, and that the documents never get seen as a whole by anyone. Out-of-context data ceases to be personal data. For machine-printed fields on documents, it is even possible to deploy “snippet digit” keying, where the field the user sees to be keyed is actually made up of extracted single characters from several documents, all glued together.
Prevalence of paper-based documents. Won’t we all be entering our own data into the Web soon?
Try telling this to my mother. Volumes of paper-based documents are increasing in some areas, decreasing in others (e.g. cheques). Even in declining areas, there is a big business opportunity as clients will want to shed the cost of these legacy documents; they will be under fierce attack by new low-cost online rivals. They will have a strong incentive to use our service.
Can you really guarantee to type everything in via snippet keying?
No. We don’t necessarily need to be able to do this either. Subscribers who come across a field that is un-keyable (for example because the client’s customer wrote outside the permitted box) will have the opportunity to mark the document as un-enterable; it will then be handled by the client’s own staff (who can see the whole document) as an exception item. Some data may indeed be too sensitive, or too hard to image or extract. This proposal is not a panacea.
Integration and IPR. You’re going to have to integrate with the back-end of complex banking systems. The operators of these often don’t own the intellectual property rights or have access to the source code. How are you going to get the images out, and the data back in?
Firstly, some systems will already have an open interface. Secondly, some other systems will have interfaces that are readily adapted; for example if images are stored in flat files and the data is inserted via known database tables or procedures. Otherwise, the client may have to buy the IPR, or we may need to cut the IPR owner in on the deal.
Character recognition technology. Surely you won’t need people to type in documents as it can all be done by machine recognition?
You haven’t tried reading my hand-writing, and you certainly haven’t tried keying in doctor’s scribbles on health insurance claim forms. Whilst automatic read-rates for magnetic-ink codelines on cheques etc. are extremely high, those for machine-printed characters are merely quite good, and handwriting recognition still has a long way to go. We also shouldn’t forget the market for non-western character sets, such as Japanese.
Bulk data-entry outsourcing. There are already operators who take your boxes of forms and key them in, possibly using third-world labour. How is this different? They are already well established in the market.
They have a fixed supply of labour, so can’t respond to changes in demand in the way we can. Taking on a high-volume contract with very variable data volumes would be risky for them. They are also much more likely to suffer outages due to a lack of geographical and network dispersion. Furthermore, some types of data entry will be language-specific. Indians are unlikely to be very productive at keying in Japanese names and addresses.
Regulation of labour supply. This sort of thing could erode the income tax base, and undermine employment law.
We’ll just have to work within whatever constraints the law imposes. Of course, we have complete freedom as to with which tax regime we base the company and the Web servers.
It’s immoral to have such a Dickensian employment policy, and to put so many people out of work. Surely it will be terrible PR for any organisation that became a client?
What is wrong with supplying safe, convenient, and (to them) well-paid work to people in developing economies? This coin has two sides.
Regulation of data export. What if laws prevent you exporting data, even in snippet form? Or even allowing the public to see the data at all?
We can operate even with these restrictions. Subscribers can be geographically restricted (e.g. by having to supply a social security number). They can be made to sign binding non-disclosure agreements. Indeed, if necessary they could be taken on as fully-blown employees.
Supply of labour and guaranteed delivery. How can you be sure that all the data that needs entering will be entered on time, when you have such a tenuous relationship with your subscribers?
We will rely on the price mechanism combined with advanced forecasting techniques. If a sudden surge in demand occurs, subscribers will be alerted (by e-mail, SMS message, or whatever) that an exceptionally high price is on offer. We will have to continually monitor the subscriber base to ensure we have the capacity to take on each new client.
The Internet isn’t reliable enough, and is full of hackers
An outage of even a few hours is potentially recoverable by simply alerting subscribers to the high rates available to key urgent data following the outage. With careful design hacker attacks such as “distributed denial of service” can also be resisted. (One way is to set up your own closed internet service provider for dial-in subscribers.) Remember that the Internet was designed with the express purpose of surviving nuclear attack. Anyway, we don’t need 100% perfection; we just need to beat the number of days lost to industrial action, random national holidays and paralysing transport strikes clients currently suffer.
Back-end integration. Isn’t this going to cost a fortune?
True, it won’t be cheap. We are likely to be talking of hundreds of thousands of pounds, maybe even a few million for a particularly large client. But compared to eliminating the employment costs of 100 people in Scandinavia, that’s good value for money. Furthermore, it is a one-off cost, whereas the saving is ongoing.
Subscribers won’t have Internet access.
The availability of access will be reflected in the price: at first, Western wages may be on offer. This will be highly attractive to anyone elsewhere who has Internet access. It may be possible to justify the cost of donating equipment and Internet access (based on keying a certain value of data). It is also possible a sub-market could evolve where local suppliers of cheap Internet access provide premises and access for on-line work in return for a fee.
Complex data entry. Some data entry is very complex, requiring detailed knowledge of the business and exception rules, and therefore considerable training and supervision. What about that?
We may or may not be able to deal with this scenario. We could possibly key in the raw data for later examination by a human operator. There will be plenty of basic data entry to keep the business well-supplied with clients.
Industries with a strong network effect (e.g. on-line auctions) also give the greatest first-mover advantage. Speed of deployment is therefore of the essence. The immediate next steps are as follows:
This proposal is really part of a bigger picture. What I've proposed - snippet data entry - grabs one of the lower hanging fruit on a big tree. In the longer run, what I'd like to create is a form of exchange for unskilled and semi-skilled on-line labour.
As a starting point, consider AutoXchange. This provides a way for absolutely anybody to come and supply Ford with good and services. The main innovations in B2B exchanges such as this are
(i) that suppliers you have no previous relationship with (and maybe even no knowledge of) can bid - thus eliminating many of the supplier acquisition costs; and
(ii) all bids are done in an automated, competitive, real-time auction system, eliminating much of the contract price negotiation costs.
It is not the existence of an exchange per se that enables us to get the lowest possible price - there was nothing stopping us from locating these suppliers and negotiating these prices; rather, it is the ability to address a wider set of potential suppliers more efficiently.
We could replicate these innovations, but in a "C2B" environment. (Unfortunately, "C2B" already has a semi-official meaning associated with it that doesn't fit this model, but it's the best term we've got.) We therefore create LaborXchange.com, where anybody can come and supply labour on-line. It is important to highlight that I'm proposing that the actual work is performed on-line; it is not at all like a conventional employment site where just information about off-line jobs is traded.
This form of on-line work exists in some forms already for high-skilled work - there are already sites where you can go and ask for someone to code up a program spec, and someone in India can bid for it; or get medical or legal advice. What I don't think anyone has hit upon is creating an environment where unskilled and semi-skilled work can be done on-line, by anyone - anywhere in the world - willing to do it for the lowest price.
Only a select range of low-skill jobs will be suitable for this treatment, of course, but out of the millions of people doing clerical work, data entry and call centre handling, there must be a large selection which could be outsourced over the Internet. Some examples of where the ideas in this proposal could be applied include:
Incidentally, in this last case they already use the idea of inserting “known result” items by super-imposing images of guns and explosives on suitcases to keep staff on their feet.
Other examples include the following.
One possible future for the enterprise is as a portal for all on-line work. The extensibility of the concept depends on the number of business processes than exist which contain labour-intensive sub-tasks which are information dependent.
If this can be made to work, it potentially addresses a vast unexplored market.
Posted by Martin Geddes at 11:17 AMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/599