Hacker News new | past | comments | ask | show | jobs | submit login

it's too difficult to build a "one size fits all" application. as an example, target has one goal with their cashiers: a fast checkout process. so they start a timer when the first item is scanned, and that timer only stops once the receipt has been printed. i was just at a target last week and the cashier told me she had to pause the transaction while someone found something i had asked to be put on hold; she was actually worried about receiving a low score. the score looks like this: 92% A, or 85% B, etc.

so target's "reward" mechanism is partially built into their POS machines, while the other part is driven by their management. if you sell more than 3 target cards in a day, you can pick out anything in the store <$20 for free. that could be built, but it'd have to be tied into target's hardware to work. and how are you going to give those badges away in that case?

i guess i'm not sold on the idea because i don't see any specific examples of where it would be compelling. maybe web-based companies, at that point your main goals are things like code written or commits. so you could monitor all employee's github accounts (as an example) and send out a company e-mail with badges based on that. just an example.




I think the most appealing market are government agencies and large corporations with lots of paperwork, such as insurances.

The process of managing a customer request in an insurance company goes like this: file the request, create a template mail, press "send", have it printed. Why not stir that up a little?


Presumably Target would know to throw out the outlying data points, but that doesn't mean the cashiers know they're allowed to take a few minutes to help the customers.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: