Delivery Person Pays First
The current functionality of EveryoneDelivers.com allows for the listing of delivery requests, browsing requests, and claiming a request. There is a lot more to getting a delivery job done, including payment and feedback. There are a number of workable models on who pays what first and division of responsibility. Below is the method I feel is the best start for performing deliveries.
One way to think of this setup is that the delivery person is selling the item to the listing person at their doorstep. The listing person helps the delivery person make a sale by specifying exactly what they want, but a sale is not guaranteed. For brevity I’m going to use two made-up words, the ‘lister’ is the person making the delivery request and the ‘fufiller’ is the person making the delivery. The most common use case, I imagine, is having the fufiller purchase the item from a store, then making the delivery.
First step: Accepting the delivery on the website. lister risk: none, fufiller risk: none.
Second step: The delivery person travels to the store and fronts the money to buy the item. Risk: fufiller has spent X of their own money in exchange for the item. Considerations: Make 100% sure you are buying the right item. Ideas on how to help with this: a UPC code in the delivery listing (for items with a UPC code)
Third step: Deliver the item to the destination address. Case: lister denies the item. It is the lister’s prerogative to deny the item at any time for any reason. The fufiller is then stuck with the item and is out the cash. The fufiller may be able to return the item to the store. Case: Lister accepts the item. The lister paypal’s the retail amount plus bounty amount to the fufiller’s paypal address. The lister reveals a code to the fufiller that allows the fufiller to mark on the website that the delivery was completed successfully. This increases the history/reputation of the fufiller and lister.
These steps eliminate a whole category of problems of the lister fronting money while the fufiller walks away with it. It provides a back-out strategy for the fufiller (with returnable items) but more risk is put on the fufiller than the lister. This is because the fufiller profits by making deliveries. Even in the rare case of making a delivery, being denied, and not being able to return the item, a history of successful deliveries will provide enough profit to insulate against the occasional failure.
I expect in the future that there will be a selection of mechanisms the lister can elect to use, such as delivery person pays first, listing person pays first, listing person pays retail first bounty later.
Perhaps there needs to be some assumed risk on the part of the lister – by virtue of using EveryoneDelivers, you’re obligated to pay the deliverer the bounty regardless of whether or not you want the item. The deliverer assumes the risk of the item, the lister assumes the responsibility of the delivery. It doesn’t even out, but the deliverer always knows that there’s some risk for the lister.
Of course, there’s no guarantee that the lister is going to pay anyway. He may simply say no when the deliverer arrives. That’s where the reputation system comes in. That may be more than a simple “Delivered?” yes or no. It could provide 3 independent ratings “Courtesy, Promptness,______” which combine to make a score. That evolves from there: A lister could value Promptness over courtesy, and the system could better match a pair.