11 ms·

Payment systems while working at a pizza place

260 points by nickjj 3y ago

deleted 3y ago
[deleted]
mschuster91 3y ago
> You would still want that free pie to be put through the workflow and tracked. The only difference is you wouldn’t collect a payment. In some jurisdictions you don't just want to put the pie through the POS system, you have to for both tax reasons and to make sure your employees don't ring up their friends on "faked" coupons. The rest of the article is really nice as well and reflects with my personal experiences in bartending... indeed having experience in hospitality jobs is a major plus for anyone working in IT or design, simply because you learn to value first hand how important performance and good UX is at some of the highest-stress jobs there are.
- ilyt 3y ago
  Or really in any job in general where you actually use the tool for longer periods of time. So that "eh, it's not that slow" and "It's only extra click" will bother you to no end when you have to constantly waste time on it.
  - aquariusDue 3y ago
    The value of domain expertise in combination with technical expertise cannot be overstated.
- sowbug 3y ago
  Lots of retail businesses have a sign that reads "If you don't receive a receipt, your purchase is free!" It enlists the customer as an auditor to make sure the employee uses the POS system, rather than pocketing the customer's payment. If the cash in the till doesn't match receipts at the end of the day, the proprietor knows something's wrong. (Just in case you're one of today's lucky 10,000.)
  - morelisp 3y ago
    Unless you know the owner is a Mensch, don’t be a narc. Let the underpaid overworked employee pocket whatever. Whole Foods doesn’t fucking care. Temporarily embarrassed millionaires eat my ass.
    - pc86 3y ago
      Until you have a problem, and don't have a receipt, and now you're out your money with a defective product and nothing to do except - buy a new one, I guess? And I'm not sure what makes you think the person buying the thing is doing any better financially than the person ringing them up. Working class people shop too. You're letting your Poli Sci 101 take on class and economics cloud the fact that it's most likely another working class person getting taken advantage of.
      - sowbug 3y ago
        The relevant parties aren't the cashier and the buyer. They're the cashier and the business owner. The whole scheme is meant as a deterrent, not as a remedy. If the buyer observes that the cashier isn't ringing up the sale, and the buyer challenges the cashier, the cashier will say "oops!" and proceed to ring it up correctly. That's because the cashier has nothing to gain by continuing the deceit at that point; either he's just letting people walk out without paying (thus risking being fired for no gain), or he's back to doing his job of collecting revenue in exchange for his wage. In any rational play of this game, the buyer ends up the same -- paying what he owed for the sale. This assumes, of course, that everyone is behaving rationally. If you believe grocery stores are evil, as the parent comment suggests, I suppose you also believe you have license to make up your own rules.
    - arcanemachiner 3y ago
      A memetic formula for societal decay has never been expressed so succinctly. It's "Fuck you, got mine" all the way down.
      - morelisp 3y ago
Doches 3y ago
I'll chime in with a lesson learned from my own experience in niche POS systems: it can be amazingly valuable (in certain contexts) to let clerks pause sales and put them off to one side (think "git stash", but for sales). Customers wander in and out, run back for one more thing, or put things on hold while they go out to get cash out of an ATM. Letting a clerk wrap up a whole sale with context (some items rung up, payments created but not processed, etc.) and put it on a shelf to restore later is a superpower for POS systems. And that's not even _starting_ on the nonsense and bizarre home-rolled systems that small businesses concoct around layaways.
- craftkiller 3y ago
  I used to work in a supermarket without this feature and when a customer would run away mid-order, my options were either stand there awkwardly while another potentially irate customer stares at me or call over a manager to get the override key to let me cancel the order (any voids/cancels over a certain dollar amount required a manager override key). Neither option was good. Both wasted time and created a bad experience for the customers. I occasionally see cashiers these days doing these `git stash` maneuvers and honestly I get jealous every time.
  - Arrath 3y ago
    It was an option in the register when I was a cashier during the crash of '08 and I couldn't find a gig elsewhere. But it was against policy to use the feature, since previous cashiers had worked out a way to scam the system somehow and pocket some of the cash being exchanged. I'm cloudy on the exact details after so long, but it was very, very annoying to have such a useful feature sitting there mocking me and a write up if I dared hit the button.
    - mgkimsal 3y ago
      Instead of dealing with the offenders... punish everyone - workers and customers (with delayed/crappy checkout experiences). That's great management, sure. Situations like these - which I noticed as a kid - contributed to my early-onset cynicism.
tennisflyi 3y ago
Has Undercover Boss taught nothing. Things are never how you think they’ll be with boots on the grounds. DoorDash was so right making devs do like an hour of actual gigging. Yeah, shit is really pretty and seamless from your Herman Miller chair and Uplift desk…
- _ea1k 3y ago
  This is also true for regulatory regimes. I've been shocked at how cavalierly some regulators will treat decisions that have career altering consequences for those being regulated. It doesn't just affect the regulations, it also means their entire mental model of how the regulated will behave can be wrong.
  - pc86 3y ago
    This is what happens when you view your job as "make regulations" (or even worse, enforce the ideological will of $PERSON on $INDUSTRY) instead of "make $INDUSTRY safer and better for consumers and the public."
- tracerbulletx 3y ago
  Yeah builders should understand the domain they're building for as well as humanly possible. On the topic of chairs, imagine the difference between a chair built by someone who has never sat in one, and someone who is absolutely passionate about sitting in chairs and is looking to build the perfect most comfortable one. It's actually deranged that such a large portion of the software industry has built up an insane game of telephone between the builders and the users and convinced people that it's an essential practice for success.
- extragood 3y ago
  I knew an early dev at DoorDash, and he hated that policy. That said, I personally agree with that approach. It's the practical vs academic argument: the ideal is both. Anecdotally, the most productive dev on my team was hired from a customer of ours where he personally used and integrated with our software.
- MikePlacid 3y ago
joshu 3y ago
> That means you shouldn’t have something like a reference to a product’s foreign key to dynamically grab the price when you render the receipt. This is vastly underrated principle that is rarely understood and should be much broadly applicable. My data is separate from other people's data. In Carta, I have had my startup investments leave the system (die, acquired, etc) and I am left taking screenshots of everything because my records are just foreign keys into some other data store. If they had mailed me PDFs even paper or something, I would be fine.
- shortcake27 3y ago
  I feel like this is one of those cases where people take a mantra too seriously. Storing values that could otherwise be derived results in complexity and discrepancy. This may lead people to the conclusion that all values which can be derived should be derived, but in the case of a receipt/invoice, this is not the right call. Discretion must be applied.
  - joshu 3y ago
    your comment doesn't provide when to decide one way or the other, which makes it more warning and less useful. when the data is stuff that could be paperwork - you get a copy, i get a copy - it should not be the case that one side gets to unilaterally decide if the data is deleted or modified.
    - shortcake27 3y ago
      I am in agreement with you. I’m just saying that developers need to apply discretion rather than following arbitrary “rules” or “patterns”. When to store or derive depends on the use case, of which are infinite.
    - mrighele 3y ago
      I think it is not difficult to decide: sometimes you want to reference an entity with its current state, some other times you mean with the properties that it has at a specific point in time. For example if I don't pay yearly tax on my car I will receive a fine. The fine may arrive one or two year later, but it should be sent to me even if I sold the car meanwhile, because what matters is that I was the owner at the time. On the other side, the fine should be sent to my current address, not the one I had when I forgot to pay. There a number of ways to handle this. The simplest is to make a copy of the data, but you can also decide to keep all the historical data and reference the state during a certain time interval. Both can be valid choices, depending on the context, frequency of change, number of references....
weard_beard 3y ago
20 years as an eCommerce developer/architect. This is really good for a first take. It covers quite a lot of what we document in most of our initial pre-project planning sessions. A couple considerations not covered here that we would dig into are: .05) Integrations! A Point of Sale and a Website an Enterprise Record System, a Product Information Management tool, A content management and authoring tool, A digital image and media management tool, Warehouse management and Order management software, and Business Intelligence Data Lake, Customer Data Platform, Email Marketing Platform, Ratings and Reviews Service, Search, and a rainbow of minor 3rd party web based services don't really help much unless they all talk to each other. Nowadays, you also need a way to mix the data from all these services together to provide unified data management and a unified user experience. To achieve this we usually build a dedicated orchestration layer to handle the services that merge data from all these sources. 1) Products. Bundles, Groups, Configurables, Packs that can or cannot be split, special pricing (distinct from discounts), add-ons, virtual products, inventory, stocking from warehouse, resale through market places or other omnichannel availability, attributes that affect pricing or shipping or purchase availability, etc. 2) Order Management. Order modification and workflows for different types of returns and exchanges. How long/can orders be modified between placement and delivery. How are chargebacks and price differences handled? What's the workflow? How is manufacturing/warehouse/shipping notified? 3) Sales channels. Specifically BOPIS (Buy Online, Pickup In Store) inter-store transfers for sales, or inventory stocking), delivery types (freight, refrigerated, courier, plus the usual UPS/USPS/FedEx options). Return and delivery tracking services and customer assistance programs. 4) Reporting. Financial, marketing, service and technical performance, Data Warehousing and Cross functional Business Intelligence, taxes, refunds, breakage, etc. 5) Customer service integrations, customer management, customer support, ticketing and tracking through customer data platforms like Salesforce. 6) Loyalty and reward programs including virtual and physical ledgers of points and campaigns to earn points. Loyalty as payment type. Ratings and reviews. Social media engagement. Gift cards. 7) Transactional communications systems such as email, text, and social media integrations, mailing lists, newsletters, and push notifications. 8) Multi-language and international sales considerations. There is a LOT to consider here. From tax to payment types, to product availability and shipping. 9) There is a mention of payment types, but payments get so much more complex than what is covered here. Who is your merchant bank? What payment gateway to use? International payments get even more complex. When to auth and capture. Services to tokenize and preserve payment info for future purchases or changing order amounts. 10) Fraud detection for payments. Mitigating carding attacks and other fraud attempts through monitoring and 3rd party integration. 11) Recurring payments/subscriptions.
JohnFen 3y ago
When they first started calling these systems "POS", I thought that it was an unfortunate coincidence that they used the common acronym for "piece of shit". But later, I began to wonder if it wasn't intentional, a kind of inside joke.
- robotnikman 3y ago
  Some people on the IT side where I work who deal with these things on a daily basis do that. Even I sometimes see POS as "piece of shit" now, even though whatever documentation I'm reading is obviously referring to 'Point of Sale'
- Verdex 3y ago
  Regan faced the engineers and fought to keep the annoyance from reaching his face. "What did you call it?" "POS." Brenda's bubbly demeanor was reflected in a little dance that she did while saying each letter in an almost singsong pattern. "You ..." Regan stops fighting his instincts, takes off his glasses, bows his head, and pinches his nose. "All of you understand that we can't call it that." The rest of the engineers stood silently and without movement. They have to have planned it this way. He should have known something was up from the moment he walked in here. "Why's that?" Brenda tilts her head to the side. "Because it stands for piece of ..." "Point of sale." Brenda blurts out before Regan can finish. Regan slowly puts his glasses back on. "Is the POS going to be completed by the deadline?" He forces the words out through a clenched jaw. Brenda remains still with wide eyes and a frozen smile on her face. The rest of the room nods that the deadline will be met. "Then fine." Regan leaves; they can make the deadline then they can have their stupid little name.
mmackh 3y ago
Began my coding career because of the family hotel business. Started coding websites, progressed onto building status boards (vertically mounted tvs) for the today’s Programm, dabbled in document management (instapdf.com), employee management (baseping.com) and worked my way up to actually implementing 3 different versions of iOS apps interfacing with different POS systems (ordervisto.com). Getting live feedback from these systems was invaluable and really helped with finding out what works and what doesn’t instantly. The hotel is sold now and I’m wondering if I’ll ever work in such a challenging and multifaceted environment again.
tolien 3y ago
> For example, if a pie costs $16.95 right now and you have 1,000 orders that happened in the past at that price and then bump your pie to $17.95 you can’t go back and adjust all of those previous orders to have $17.95. > Just about everything about that receipt should be denormalized, AKA. the details about the receipt are all self contained in that 1 row. The way I'd probably model this would be to mark the $16.95 pie as deleted/deprecated/no longer for sale and create a duplicate entry with the price changed to $17.95, rather than creating copies of all of the product details each time I record a sale.
- scottcodie 3y ago
  You could also use a temporal table.
- heywire 3y ago
  Traditional point of sale systems generally have the notion of a “transaction log” or “tlog” which is a sequence of events within the transaction including items sold and their price at the time.
- duskwuff 3y ago
  > The way I'd probably model this would be to mark the $16.95 pie as deleted/deprecated/no longer for sale... That technically works, but it plays hell with reporting and stockkeeping. The latter of which isn't a problem for pizza, of course, but can be significant in other sectors. (Nobody wants to have to keep track of a stock of "$16.95 widgets" separate from a stock of identical "$17.95 widgets".) But there's enough other data in a receipt/invoice which needs to not change after the invoice is created, like tax rates, that it really is best to make the whole thing self-contained and immutable. Being able to confidently make statements like "yes, this is exactly the same invoice that we presented to the customer 3 years ago, and nothing about it has changed" can be incredibly important as well.
  - weard_beard 3y ago
    How its handled in the system I work in is that a copy the product data is made to a new object. That new object gets converted to a final invoice eventually. A product is copied to a quote (or cart) item. A cart item is copied to an order item. A receipt or invoice is generated from an order and its items. The price of products and all their attributes can be changed without the SKU or identifier changing, but the quote, order, and invoice item is an immutable artifact. The key problem with this system is order modifications. In order to modify an order you cancel and recreate the order from scratch. We get around this usually by piping the orders to a dedicated order management system and when orders are finalized/auth'd captured/shipped there is one final order modification that comes back to the system to capture the final state and we don't update orders continuously. This way customers see their final order state, but we don't have to cancel/recreate every change to the order along the way.
mprovost 3y ago
Back in college we ordered pizza and when the driver arrived there was some confusion finding money for a tip and after he was gone we realised that three of us had given him cash. After that every time we ordered it seemed like the pizza arrived in minutes. We assumed that someone had put a note in their system next to our phone number like "amazing tippers".
- hot_gril 3y ago
  There are a few nice restaurants where I've given a normal tip but in cash, which isn't common there, and it seems like waiters remember me (in a good way) just because of that.
addisonj 3y ago
What an interesting and timely article. My extended family recently opened a pizza place which just happened to be at the same time as me wanting to take a break from startup grind. I worked at a pizza place in high school, and have continued to make pizza at home, and loved the idea of being able to combine that knowledge with the experience of building software startups, so I have been heavily involved in the last 6 weeks on everything from ordering, to kitchen layout, to POS and other IT systems, to marketing. In short, the experience has been super interesting, not only in terms getting to learn tons of new things and get familiar with how the tech side is done (spoiler alert, not that well) but also just generally how much of an opportunity there is to take the sort of thinking and skills required to build tech products and to apply them to a quick-serve restaurant (and I would guess lots of other small business). I have been planning on writing something up, but this article is giving me good motivation to actually do it :)
- Freedom2 3y ago
  I wouldn't be surprised if the author visited your newly opened place and was inspired to write the article based off their experiences! It's a small world, after all.
- genmud 3y ago
  You should talk to some of your local newspapers/culture magazines about your experience as well, they love these types of stories and you can get free exposure for it.
joshstrange 3y ago
I work for a POS company and yeah, it's crazy how much more complex something like this is than you think at first. Another wrinkle that wasn't covered in this post: variable pricing. What I mean by that can best be explained with this example: You have a S/M/L pizza but the additional toppings are priced differently for the S vs M vs L ($0.50, $1, $2). But you probably want a "Toppings" option set with choices like "Sausage, Tomatoes, etc" that's reusable across all your pizzas (for stock/reporting purposes). Also you want to be able to mark a topping as out of stock and have it apply to all your pizzas. So how do you handle the price differences? Remember this 1 option (Size) modifying the pricing for a totally different option (Toppings). Also you might want to set this on a per-pizza basis, since you also need to modify the "Toppings" option to include "Beef, Sausage, and Pepperoni" for free on the "Meat Lovers" and you also need to have some kind of handling for "2-Topping pizza" where you get 2 toppings for free then have to pay for any extras. Another fun concepts is bundles. Maybe you want to offer a pizza+2-Liter or 2 2-Toppings pizza deal. All of it gets extremely complicated very quickly. Even more fun is finding a way to translate your internal menu structure into something DoorDash/etc can understand and let me tell you, it will /not/ be a 1-to-1 mapping. Sure, for something like variable pricing you could just say "screw it" and make all additional toppings $2/each (let's pretend that's what they cost on the Large) that way you are always doing as good or better than your normal POS or you could "flatten" all your menu items so you end up shipping "Small Pizza", "Medium Pizza", etc over to DoorDash (Don't forget, you have to do that for every pizza then unflatten it on the way back into your system). Don't get me started on how DoorDash does testing, they literally use their live site for testing. There is a town in Alaska where they add your demo location to and they give you a login with a card on file that they just refund at the end of the day or something like that. It's super janky.
- nickjj 3y ago
  That's a good point about the toppings being different, especially on different types of pies or slices. For example on their personal pizza, there isn't an option for half toppings, it's full or nothing. We do have bundles, such as multiple lunch or dinner combos. They are a distinct menu item in the POS system as "Dinner combo 1" with a description of what's included. What was really fun was helping design a printed menu where we wanted to display 25 different pies in S / M / L variants as well as having gluten free options for most of them. We opted for a 3 column price layout for the 3 sizes and put gluten free in its own little section with a different way to associate the prices to at least 20 different pies since the size and price was the same for all gluten free options. It was a good lesson in dealing with "actual constraints". Especially when the font size couldn't be reduced and we couldn't use more than 1.2 pages for listing all of the pies.
user83849492 3y ago
What are the best POS systems out there?
- aaronax 3y ago
  Any that are text/TUI/"green-screen"-based are often lauded for speed once you are familiar with them, so there is that kind of best. And if they are still in use even today, then that survival is a strong point in favor of them being "the best". As far as specific products, NCR Counterpoint is one that stands out amongst those I have used. Fast and flexible, kind of easy to figure out most things on your own. The Costco cafeteria self-service kiosk seems to be an amazing POS (customer perspective). Incredibly optimized in every regard. The receipt seems to print out before you have even finished removing your card from the chip reader.
  - crazysim 3y ago
    You stick it in? Sometimes it feels faster than tapping!
- quickthrower2 3y ago
  Anecdotally (in Australia), as a customer I found the square readers [1] linked to ipads were the smoothest and quickest. And I use a mix of cards - credit, prepaid gift cards, debit. [1] Probably this thing: https://squareup.com/shop/hardware/au/en/products/chip-credit-card-reader-with-nfc-au https://squareup.com/shop/hardware/au/en/products/chip-credi...
samrolken 3y ago
As someone who has built the tech behind an online ordering platform just for pizzerias (Slice), this is all exactly on point.
- nickjj 3y ago
  Hah, it's a small world. That's the system we're using. I wonder if you could tell based on the terms I used in the post.
  - samrolken 3y ago
    That’s awesome! I can’t claim to have quite connected the dots, but it caught my eye right away and completely vibed. Great work breaking it down and writing it up so nicely!
sky_rw 3y ago
If anybody here is suddenly considering a startup in the PoS industry, please just turn around and run as fast as you can in the other direction. It's an endless pit of hell.
- deleted 3y ago
  [deleted]
hot_gril 3y ago
So if I'm familiar with databases in general and slightly familiar with financial transactions, what's the most surprising thing about the pizza payment systems in particular?
- andix 3y ago
  There are no big surprises. There are hundreds of tiny ones. You need to identify them, keep track of them and don't miss any.
andix 3y ago
I developed POS software, and it is an extremely challenging job. The workflow described in this article is still rather simple, there are so many more possibilities (some apply more to shops than restaurants). One hypothetical example: a tiramisu with coffee has a special price, but you still need to put them separately on the invoice, either because you track if the tiramisus are out of stock and want to stop people ordering more. Or coffee and tiramisu may have different sales taxes (very common in Europe to have a lower tax for food). Different prices for take away and eating in the restaurant, happy hours. Payment in different currencies, some articles may have fixed prices in a foreign currency, others need conversion with the current exchange rate. The possibility to split or join invoices. Usability and speed is crucial at the POS, the users go crazy if they are busy and their software is too slow or has too many submenus. It has to be easy to learn too, often they hire people that fill in for a few days, and they need to be able to use it. A lot of people using it are also not very skilled with computers, or have no interest in learning how to use the software. The owner may restrict some features to some users, so they can't cheat the system (taking cash payments, cancelling the invoice and keeping the money). There may be some tax fraud prevention laws to be implemented, vastly varying on the region, like digitally signed invoices or the need to report every issued invoice to the authorities in real time.
- Falkon1313 3y ago
  Those kind of tax and price variations are quite common in the U.S. too. Some examples: Bread from bakery plus lunchmeat from deli = taxed at grocery rate, but a shrinkwrapped sandwich using the same bread and lunchmeat = taxed at the higher 'prepared meal' rate (because that's a luxury). One candy bar is taxed at the grocery rate, because it includes wheat in the ingredients, while another is taxed at the junk food rate because it doesn't. They're both mostly chocolate and nougat, but one has some wheat, so it's legally considered a cereal. And of course all of that varies from town to town and state to state, and sometimes even in different neighborhoods within the same town. And of course, some towns cross those political boundaries. I used to live just down the street from a shopping center where the tax rates were different depending on which store you were in (east side of the mall vs west side of the mall). That's all before you get to sales and specials and membership discounts and such. Oh, and tax-exempt shoppers (because they work for a charity or something). People always make fun of the U.S. for not just putting the total final price (tax included) on the shelf but the reality is, we can't because quite often we just can't know what it will be until you checkout. For something that seems so simple and everyday, it really is bafflingly complex.
johanneskanybal 3y ago
Klarna has none of those issues. disclaimer: used to consult for a bit at Klarna. But payment sure is a solved problem.
- toyg 3y ago
  I recently tried to use Klarna, and I can only say that of course payment is a solved problem when you just lie to customers until it's too late in the checkout process to cancel it. Never again.
glonq 3y ago
Early in my career, I learned that it's possible to accidentally credit thousands of dollars to people's credit cards instead of charging them. On the bright side, I learned a valuable lesson and did not get fired.
retrocryptid 3y ago
In my day we didn't have a fancy computer to calculate change. We had to count up change, just like my grandpappy did in nineteen-aught-three. And change! MEH! All we had were sheets of zinc and steel and copper foil. We had to manually pound out pennies in the back of the shop in a mold stolen from the mint in DC. And even if we did get a computing device, all we had were zeros. We had to pound half of 'em into ones manually. AND WE LIKED IT THAT WAY!
squeaky-clean 3y ago
I worked at Domino's from about 2011-2013. Their digital system was really impressive to me. The POS was pretty good for fast-food. But what really impressed me was the station management system, aka the pizza tracker. An order had to be keyed in/out of each station to the next by employee pin. Each station had a screen displaying the pending and in-progress orders. It was connected to the "pizza tracker", so when it said "John is adding your toppings" it really meant someone else had keyed it out of the sauce/cheese station and "John" had keyed it into the toppings station. Orders came in from the cashier or online, then went to dough/sauce/cheese, toppings, oven, prep (cutting and garlic crust sauce, dipping addons), then delivery. Of course on things like superbowl Sunday "John" was just the manager keying in every station and deligating orders manually, because that was still slightly faster. But what really impressed me, after a few other years of various fast food jobs, was that it was not tied to any financial incentives. Managers couldn't view the historical data in any way. There were no bonuses or rewards based on it. So there was no reason to lie and send it to a new station screen early. I had worked at Burger King and Taco Bell prior. At both of those locations there was a similar, but simplified system. You keyed in an order as taken. Then as done. Then as served. From what I could tell, management bonuses were based on certain metrics on these times. The burger king actually had a single 8 segment display hanging in the kitchen showing us our current letter grade (A-F) for performance in the past hour. We were told to just key in any order that would take longer than normal as instantly done. Domino's must have had some great data to optimize their kitchens on. While BK and Taco Bell have their kitchens telling them everything is fine, because they will be punished if they say some new specialty sandwich takes too long to prepare.
- thaumasiotes 3y ago
  > Managers couldn't view the historical data in any way. There were no bonuses or rewards based on it. So there was no reason to lie and send it to a new station screen early. It seems like the system described would be resilient to that? If there were incentives, tracking, and punishment, the process still involves the earlier-stage employee keying the pizza out and then the later-stage employee keying it in. If the earlier-stage guy benefits from lying about how quickly he finishes his stage of the pizza, how does he persuade the later-stage guy to take the fall of incredible slowness by keying the pizza in to his stage early?
LelouBil 3y ago
I tried to order a pizza at a big pizza chain near me, but their website wouldn't take my address! It was one of these autocomplete drop-down but it won't let you enter anything not in the options. I tried calling them but the guy on the phone was also telling me the system wouldn't accept my address! In the end he did the delivery himself since there were not a lot of customers that day and knew the correct address.
zapkyeskrill 3y ago
[flagged]
fukawi2 3y ago
My first job was supporting and developing order related systems for retail and wholesale (separate systems, but we operated both the wholesale and retail operations). Wait until you start having to deal with Forward Orders, Back Orders, Special Orders, Cancelled Orders, and Refunds. Not to mention the General Ledger postings you have to make for each transaction too. An "order" sounds super simple, but there are so many variations and corner cases.
epa 3y ago
Every few quarters a post like this shows up on HN from an engineer who has ventured into sales reporting. Always a good reminder on why project scoping is so important!
vishnugupta 3y ago
This is a great article. IMO engineers and product managers building e-commerce and related systems should at the very least spend a few days at a physical store to observe and document how they work. A great number of engineers are asked to build software in domains for which they have very little idea. For example, Uber engineers would learn a great deal by spending a few days with a driver. They can then place their own system components in context and make sense of it all. Failing to learn domain knowledge has resulted in so many half ass wheels being reinvented.

260 points by nickjj 3y ago

deleted 3y ago

[deleted]

> You would still want that free pie to be put through the workflow and tracked. The only difference is you wouldn’t collect a payment. In some jurisdictions you don't just want to put the pie through the POS system, you have to for both tax reasons and to make sure your employees don't ring up their friends on "faked" coupons. The rest of the article is really nice as well and reflects with my personal experiences in bartending... indeed having experience in hospitality jobs is a major plus for anyone working in IT or design, simply because you learn to value first hand how important performance and good UX is at some of the highest-stress jobs there are.

ilyt 3y ago
Or really in any job in general where you actually use the tool for longer periods of time. So that "eh, it's not that slow" and "It's only extra click" will bother you to no end when you have to constantly waste time on it.
- aquariusDue 3y ago
  The value of domain expertise in combination with technical expertise cannot be overstated.
sowbug 3y ago
Lots of retail businesses have a sign that reads "If you don't receive a receipt, your purchase is free!" It enlists the customer as an auditor to make sure the employee uses the POS system, rather than pocketing the customer's payment. If the cash in the till doesn't match receipts at the end of the day, the proprietor knows something's wrong. (Just in case you're one of today's lucky 10,000.)
- morelisp 3y ago
  Unless you know the owner is a Mensch, don’t be a narc. Let the underpaid overworked employee pocket whatever. Whole Foods doesn’t fucking care. Temporarily embarrassed millionaires eat my ass.
  - pc86 3y ago
    Until you have a problem, and don't have a receipt, and now you're out your money with a defective product and nothing to do except - buy a new one, I guess? And I'm not sure what makes you think the person buying the thing is doing any better financially than the person ringing them up. Working class people shop too. You're letting your Poli Sci 101 take on class and economics cloud the fact that it's most likely another working class person getting taken advantage of.
    - sowbug 3y ago
      The relevant parties aren't the cashier and the buyer. They're the cashier and the business owner. The whole scheme is meant as a deterrent, not as a remedy. If the buyer observes that the cashier isn't ringing up the sale, and the buyer challenges the cashier, the cashier will say "oops!" and proceed to ring it up correctly. That's because the cashier has nothing to gain by continuing the deceit at that point; either he's just letting people walk out without paying (thus risking being fired for no gain), or he's back to doing his job of collecting revenue in exchange for his wage. In any rational play of this game, the buyer ends up the same -- paying what he owed for the sale. This assumes, of course, that everyone is behaving rationally. If you believe grocery stores are evil, as the parent comment suggests, I suppose you also believe you have license to make up your own rules.
  - arcanemachiner 3y ago
    A memetic formula for societal decay has never been expressed so succinctly. It's "Fuck you, got mine" all the way down.
    - morelisp 3y ago

Doches 3y ago

I'll chime in with a lesson learned from my own experience in niche POS systems: it can be amazingly valuable (in certain contexts) to let clerks pause sales and put them off to one side (think "git stash", but for sales). Customers wander in and out, run back for one more thing, or put things on hold while they go out to get cash out of an ATM. Letting a clerk wrap up a whole sale with context (some items rung up, payments created but not processed, etc.) and put it on a shelf to restore later is a superpower for POS systems. And that's not even _starting_ on the nonsense and bizarre home-rolled systems that small businesses concoct around layaways.

craftkiller 3y ago
I used to work in a supermarket without this feature and when a customer would run away mid-order, my options were either stand there awkwardly while another potentially irate customer stares at me or call over a manager to get the override key to let me cancel the order (any voids/cancels over a certain dollar amount required a manager override key). Neither option was good. Both wasted time and created a bad experience for the customers. I occasionally see cashiers these days doing these `git stash` maneuvers and honestly I get jealous every time.
- Arrath 3y ago
  It was an option in the register when I was a cashier during the crash of '08 and I couldn't find a gig elsewhere. But it was against policy to use the feature, since previous cashiers had worked out a way to scam the system somehow and pocket some of the cash being exchanged. I'm cloudy on the exact details after so long, but it was very, very annoying to have such a useful feature sitting there mocking me and a write up if I dared hit the button.
  - mgkimsal 3y ago
    Instead of dealing with the offenders... punish everyone - workers and customers (with delayed/crappy checkout experiences). That's great management, sure. Situations like these - which I noticed as a kid - contributed to my early-onset cynicism.

tennisflyi 3y ago

Has Undercover Boss taught nothing. Things are never how you think they’ll be with boots on the grounds. DoorDash was so right making devs do like an hour of actual gigging. Yeah, shit is really pretty and seamless from your Herman Miller chair and Uplift desk…

_ea1k 3y ago
This is also true for regulatory regimes. I've been shocked at how cavalierly some regulators will treat decisions that have career altering consequences for those being regulated. It doesn't just affect the regulations, it also means their entire mental model of how the regulated will behave can be wrong.
- pc86 3y ago
  This is what happens when you view your job as "make regulations" (or even worse, enforce the ideological will of $PERSON on $INDUSTRY) instead of "make $INDUSTRY safer and better for consumers and the public."
tracerbulletx 3y ago
Yeah builders should understand the domain they're building for as well as humanly possible. On the topic of chairs, imagine the difference between a chair built by someone who has never sat in one, and someone who is absolutely passionate about sitting in chairs and is looking to build the perfect most comfortable one. It's actually deranged that such a large portion of the software industry has built up an insane game of telephone between the builders and the users and convinced people that it's an essential practice for success.
extragood 3y ago
I knew an early dev at DoorDash, and he hated that policy. That said, I personally agree with that approach. It's the practical vs academic argument: the ideal is both. Anecdotally, the most productive dev on my team was hired from a customer of ours where he personally used and integrated with our software.
MikePlacid 3y ago

joshu 3y ago

> That means you shouldn’t have something like a reference to a product’s foreign key to dynamically grab the price when you render the receipt. This is vastly underrated principle that is rarely understood and should be much broadly applicable. My data is separate from other people's data. In Carta, I have had my startup investments leave the system (die, acquired, etc) and I am left taking screenshots of everything because my records are just foreign keys into some other data store. If they had mailed me PDFs even paper or something, I would be fine.

shortcake27 3y ago
I feel like this is one of those cases where people take a mantra too seriously. Storing values that could otherwise be derived results in complexity and discrepancy. This may lead people to the conclusion that all values which can be derived should be derived, but in the case of a receipt/invoice, this is not the right call. Discretion must be applied.
- joshu 3y ago
  your comment doesn't provide when to decide one way or the other, which makes it more warning and less useful. when the data is stuff that could be paperwork - you get a copy, i get a copy - it should not be the case that one side gets to unilaterally decide if the data is deleted or modified.
  - shortcake27 3y ago
    I am in agreement with you. I’m just saying that developers need to apply discretion rather than following arbitrary “rules” or “patterns”. When to store or derive depends on the use case, of which are infinite.
  - mrighele 3y ago
    I think it is not difficult to decide: sometimes you want to reference an entity with its current state, some other times you mean with the properties that it has at a specific point in time. For example if I don't pay yearly tax on my car I will receive a fine. The fine may arrive one or two year later, but it should be sent to me even if I sold the car meanwhile, because what matters is that I was the owner at the time. On the other side, the fine should be sent to my current address, not the one I had when I forgot to pay. There a number of ways to handle this. The simplest is to make a copy of the data, but you can also decide to keep all the historical data and reference the state during a certain time interval. Both can be valid choices, depending on the context, frequency of change, number of references....

weard_beard 3y ago

20 years as an eCommerce developer/architect. This is really good for a first take. It covers quite a lot of what we document in most of our initial pre-project planning sessions. A couple considerations not covered here that we would dig into are: .05) Integrations! A Point of Sale and a Website an Enterprise Record System, a Product Information Management tool, A content management and authoring tool, A digital image and media management tool, Warehouse management and Order management software, and Business Intelligence Data Lake, Customer Data Platform, Email Marketing Platform, Ratings and Reviews Service, Search, and a rainbow of minor 3rd party web based services don't really help much unless they all talk to each other. Nowadays, you also need a way to mix the data from all these services together to provide unified data management and a unified user experience. To achieve this we usually build a dedicated orchestration layer to handle the services that merge data from all these sources. 1) Products. Bundles, Groups, Configurables, Packs that can or cannot be split, special pricing (distinct from discounts), add-ons, virtual products, inventory, stocking from warehouse, resale through market places or other omnichannel availability, attributes that affect pricing or shipping or purchase availability, etc. 2) Order Management. Order modification and workflows for different types of returns and exchanges. How long/can orders be modified between placement and delivery. How are chargebacks and price differences handled? What's the workflow? How is manufacturing/warehouse/shipping notified? 3) Sales channels. Specifically BOPIS (Buy Online, Pickup In Store) inter-store transfers for sales, or inventory stocking), delivery types (freight, refrigerated, courier, plus the usual UPS/USPS/FedEx options). Return and delivery tracking services and customer assistance programs. 4) Reporting. Financial, marketing, service and technical performance, Data Warehousing and Cross functional Business Intelligence, taxes, refunds, breakage, etc. 5) Customer service integrations, customer management, customer support, ticketing and tracking through customer data platforms like Salesforce. 6) Loyalty and reward programs including virtual and physical ledgers of points and campaigns to earn points. Loyalty as payment type. Ratings and reviews. Social media engagement. Gift cards. 7) Transactional communications systems such as email, text, and social media integrations, mailing lists, newsletters, and push notifications. 8) Multi-language and international sales considerations. There is a LOT to consider here. From tax to payment types, to product availability and shipping. 9) There is a mention of payment types, but payments get so much more complex than what is covered here. Who is your merchant bank? What payment gateway to use? International payments get even more complex. When to auth and capture. Services to tokenize and preserve payment info for future purchases or changing order amounts. 10) Fraud detection for payments. Mitigating carding attacks and other fraud attempts through monitoring and 3rd party integration. 11) Recurring payments/subscriptions.

JohnFen 3y ago

When they first started calling these systems "POS", I thought that it was an unfortunate coincidence that they used the common acronym for "piece of shit". But later, I began to wonder if it wasn't intentional, a kind of inside joke.

robotnikman 3y ago
Some people on the IT side where I work who deal with these things on a daily basis do that. Even I sometimes see POS as "piece of shit" now, even though whatever documentation I'm reading is obviously referring to 'Point of Sale'
Verdex 3y ago
Regan faced the engineers and fought to keep the annoyance from reaching his face. "What did you call it?" "POS." Brenda's bubbly demeanor was reflected in a little dance that she did while saying each letter in an almost singsong pattern. "You ..." Regan stops fighting his instincts, takes off his glasses, bows his head, and pinches his nose. "All of you understand that we can't call it that." The rest of the engineers stood silently and without movement. They have to have planned it this way. He should have known something was up from the moment he walked in here. "Why's that?" Brenda tilts her head to the side. "Because it stands for piece of ..." "Point of sale." Brenda blurts out before Regan can finish. Regan slowly puts his glasses back on. "Is the POS going to be completed by the deadline?" He forces the words out through a clenched jaw. Brenda remains still with wide eyes and a frozen smile on her face. The rest of the room nods that the deadline will be met. "Then fine." Regan leaves; they can make the deadline then they can have their stupid little name.

mmackh 3y ago

Began my coding career because of the family hotel business. Started coding websites, progressed onto building status boards (vertically mounted tvs) for the today’s Programm, dabbled in document management (instapdf.com), employee management (baseping.com) and worked my way up to actually implementing 3 different versions of iOS apps interfacing with different POS systems (ordervisto.com). Getting live feedback from these systems was invaluable and really helped with finding out what works and what doesn’t instantly. The hotel is sold now and I’m wondering if I’ll ever work in such a challenging and multifaceted environment again.

tolien 3y ago

> For example, if a pie costs $16.95 right now and you have 1,000 orders that happened in the past at that price and then bump your pie to $17.95 you can’t go back and adjust all of those previous orders to have $17.95. > Just about everything about that receipt should be denormalized, AKA. the details about the receipt are all self contained in that 1 row. The way I'd probably model this would be to mark the $16.95 pie as deleted/deprecated/no longer for sale and create a duplicate entry with the price changed to $17.95, rather than creating copies of all of the product details each time I record a sale.

scottcodie 3y ago
You could also use a temporal table.
heywire 3y ago
Traditional point of sale systems generally have the notion of a “transaction log” or “tlog” which is a sequence of events within the transaction including items sold and their price at the time.
duskwuff 3y ago
> The way I'd probably model this would be to mark the $16.95 pie as deleted/deprecated/no longer for sale... That technically works, but it plays hell with reporting and stockkeeping. The latter of which isn't a problem for pizza, of course, but can be significant in other sectors. (Nobody wants to have to keep track of a stock of "$16.95 widgets" separate from a stock of identical "$17.95 widgets".) But there's enough other data in a receipt/invoice which needs to not change after the invoice is created, like tax rates, that it really is best to make the whole thing self-contained and immutable. Being able to confidently make statements like "yes, this is exactly the same invoice that we presented to the customer 3 years ago, and nothing about it has changed" can be incredibly important as well.
- weard_beard 3y ago
  How its handled in the system I work in is that a copy the product data is made to a new object. That new object gets converted to a final invoice eventually. A product is copied to a quote (or cart) item. A cart item is copied to an order item. A receipt or invoice is generated from an order and its items. The price of products and all their attributes can be changed without the SKU or identifier changing, but the quote, order, and invoice item is an immutable artifact. The key problem with this system is order modifications. In order to modify an order you cancel and recreate the order from scratch. We get around this usually by piping the orders to a dedicated order management system and when orders are finalized/auth'd captured/shipped there is one final order modification that comes back to the system to capture the final state and we don't update orders continuously. This way customers see their final order state, but we don't have to cancel/recreate every change to the order along the way.

mprovost 3y ago

Back in college we ordered pizza and when the driver arrived there was some confusion finding money for a tip and after he was gone we realised that three of us had given him cash. After that every time we ordered it seemed like the pizza arrived in minutes. We assumed that someone had put a note in their system next to our phone number like "amazing tippers".

hot_gril 3y ago
There are a few nice restaurants where I've given a normal tip but in cash, which isn't common there, and it seems like waiters remember me (in a good way) just because of that.

addisonj 3y ago

What an interesting and timely article. My extended family recently opened a pizza place which just happened to be at the same time as me wanting to take a break from startup grind. I worked at a pizza place in high school, and have continued to make pizza at home, and loved the idea of being able to combine that knowledge with the experience of building software startups, so I have been heavily involved in the last 6 weeks on everything from ordering, to kitchen layout, to POS and other IT systems, to marketing. In short, the experience has been super interesting, not only in terms getting to learn tons of new things and get familiar with how the tech side is done (spoiler alert, not that well) but also just generally how much of an opportunity there is to take the sort of thinking and skills required to build tech products and to apply them to a quick-serve restaurant (and I would guess lots of other small business). I have been planning on writing something up, but this article is giving me good motivation to actually do it :)

Freedom2 3y ago
I wouldn't be surprised if the author visited your newly opened place and was inspired to write the article based off their experiences! It's a small world, after all.
genmud 3y ago
You should talk to some of your local newspapers/culture magazines about your experience as well, they love these types of stories and you can get free exposure for it.

joshstrange 3y ago

I work for a POS company and yeah, it's crazy how much more complex something like this is than you think at first. Another wrinkle that wasn't covered in this post: variable pricing. What I mean by that can best be explained with this example: You have a S/M/L pizza but the additional toppings are priced differently for the S vs M vs L ($0.50, $1, $2). But you probably want a "Toppings" option set with choices like "Sausage, Tomatoes, etc" that's reusable across all your pizzas (for stock/reporting purposes). Also you want to be able to mark a topping as out of stock and have it apply to all your pizzas. So how do you handle the price differences? Remember this 1 option (Size) modifying the pricing for a totally different option (Toppings). Also you might want to set this on a per-pizza basis, since you also need to modify the "Toppings" option to include "Beef, Sausage, and Pepperoni" for free on the "Meat Lovers" and you also need to have some kind of handling for "2-Topping pizza" where you get 2 toppings for free then have to pay for any extras. Another fun concepts is bundles. Maybe you want to offer a pizza+2-Liter or 2 2-Toppings pizza deal. All of it gets extremely complicated very quickly. Even more fun is finding a way to translate your internal menu structure into something DoorDash/etc can understand and let me tell you, it will /not/ be a 1-to-1 mapping. Sure, for something like variable pricing you could just say "screw it" and make all additional toppings $2/each (let's pretend that's what they cost on the Large) that way you are always doing as good or better than your normal POS or you could "flatten" all your menu items so you end up shipping "Small Pizza", "Medium Pizza", etc over to DoorDash (Don't forget, you have to do that for every pizza then unflatten it on the way back into your system). Don't get me started on how DoorDash does testing, they literally use their live site for testing. There is a town in Alaska where they add your demo location to and they give you a login with a card on file that they just refund at the end of the day or something like that. It's super janky.

nickjj 3y ago
That's a good point about the toppings being different, especially on different types of pies or slices. For example on their personal pizza, there isn't an option for half toppings, it's full or nothing. We do have bundles, such as multiple lunch or dinner combos. They are a distinct menu item in the POS system as "Dinner combo 1" with a description of what's included. What was really fun was helping design a printed menu where we wanted to display 25 different pies in S / M / L variants as well as having gluten free options for most of them. We opted for a 3 column price layout for the 3 sizes and put gluten free in its own little section with a different way to associate the prices to at least 20 different pies since the size and price was the same for all gluten free options. It was a good lesson in dealing with "actual constraints". Especially when the font size couldn't be reduced and we couldn't use more than 1.2 pages for listing all of the pies.

user83849492 3y ago

What are the best POS systems out there?

aaronax 3y ago
Any that are text/TUI/"green-screen"-based are often lauded for speed once you are familiar with them, so there is that kind of best. And if they are still in use even today, then that survival is a strong point in favor of them being "the best". As far as specific products, NCR Counterpoint is one that stands out amongst those I have used. Fast and flexible, kind of easy to figure out most things on your own. The Costco cafeteria self-service kiosk seems to be an amazing POS (customer perspective). Incredibly optimized in every regard. The receipt seems to print out before you have even finished removing your card from the chip reader.
- crazysim 3y ago
  You stick it in? Sometimes it feels faster than tapping!
quickthrower2 3y ago
Anecdotally (in Australia), as a customer I found the square readers [1] linked to ipads were the smoothest and quickest. And I use a mix of cards - credit, prepaid gift cards, debit. [1] Probably this thing: https://squareup.com/shop/hardware/au/en/products/chip-credit-card-reader-with-nfc-au https://squareup.com/shop/hardware/au/en/products/chip-credi...

samrolken 3y ago

As someone who has built the tech behind an online ordering platform just for pizzerias (Slice), this is all exactly on point.

nickjj 3y ago
Hah, it's a small world. That's the system we're using. I wonder if you could tell based on the terms I used in the post.
- samrolken 3y ago
  That’s awesome! I can’t claim to have quite connected the dots, but it caught my eye right away and completely vibed. Great work breaking it down and writing it up so nicely!

sky_rw 3y ago

If anybody here is suddenly considering a startup in the PoS industry, please just turn around and run as fast as you can in the other direction. It's an endless pit of hell.

deleted 3y ago
[deleted]

hot_gril 3y ago

So if I'm familiar with databases in general and slightly familiar with financial transactions, what's the most surprising thing about the pizza payment systems in particular?

andix 3y ago
There are no big surprises. There are hundreds of tiny ones. You need to identify them, keep track of them and don't miss any.

andix 3y ago

I developed POS software, and it is an extremely challenging job. The workflow described in this article is still rather simple, there are so many more possibilities (some apply more to shops than restaurants). One hypothetical example: a tiramisu with coffee has a special price, but you still need to put them separately on the invoice, either because you track if the tiramisus are out of stock and want to stop people ordering more. Or coffee and tiramisu may have different sales taxes (very common in Europe to have a lower tax for food). Different prices for take away and eating in the restaurant, happy hours. Payment in different currencies, some articles may have fixed prices in a foreign currency, others need conversion with the current exchange rate. The possibility to split or join invoices. Usability and speed is crucial at the POS, the users go crazy if they are busy and their software is too slow or has too many submenus. It has to be easy to learn too, often they hire people that fill in for a few days, and they need to be able to use it. A lot of people using it are also not very skilled with computers, or have no interest in learning how to use the software. The owner may restrict some features to some users, so they can't cheat the system (taking cash payments, cancelling the invoice and keeping the money). There may be some tax fraud prevention laws to be implemented, vastly varying on the region, like digitally signed invoices or the need to report every issued invoice to the authorities in real time.

Falkon1313 3y ago
Those kind of tax and price variations are quite common in the U.S. too. Some examples: Bread from bakery plus lunchmeat from deli = taxed at grocery rate, but a shrinkwrapped sandwich using the same bread and lunchmeat = taxed at the higher 'prepared meal' rate (because that's a luxury). One candy bar is taxed at the grocery rate, because it includes wheat in the ingredients, while another is taxed at the junk food rate because it doesn't. They're both mostly chocolate and nougat, but one has some wheat, so it's legally considered a cereal. And of course all of that varies from town to town and state to state, and sometimes even in different neighborhoods within the same town. And of course, some towns cross those political boundaries. I used to live just down the street from a shopping center where the tax rates were different depending on which store you were in (east side of the mall vs west side of the mall). That's all before you get to sales and specials and membership discounts and such. Oh, and tax-exempt shoppers (because they work for a charity or something). People always make fun of the U.S. for not just putting the total final price (tax included) on the shelf but the reality is, we can't because quite often we just can't know what it will be until you checkout. For something that seems so simple and everyday, it really is bafflingly complex.

johanneskanybal 3y ago

Klarna has none of those issues. disclaimer: used to consult for a bit at Klarna. But payment sure is a solved problem.

toyg 3y ago
I recently tried to use Klarna, and I can only say that of course payment is a solved problem when you just lie to customers until it's too late in the checkout process to cancel it. Never again.

glonq 3y ago

Early in my career, I learned that it's possible to accidentally credit thousands of dollars to people's credit cards instead of charging them. On the bright side, I learned a valuable lesson and did not get fired.

retrocryptid 3y ago

In my day we didn't have a fancy computer to calculate change. We had to count up change, just like my grandpappy did in nineteen-aught-three. And change! MEH! All we had were sheets of zinc and steel and copper foil. We had to manually pound out pennies in the back of the shop in a mold stolen from the mint in DC. And even if we did get a computing device, all we had were zeros. We had to pound half of 'em into ones manually. AND WE LIKED IT THAT WAY!

squeaky-clean 3y ago

I worked at Domino's from about 2011-2013. Their digital system was really impressive to me. The POS was pretty good for fast-food. But what really impressed me was the station management system, aka the pizza tracker. An order had to be keyed in/out of each station to the next by employee pin. Each station had a screen displaying the pending and in-progress orders. It was connected to the "pizza tracker", so when it said "John is adding your toppings" it really meant someone else had keyed it out of the sauce/cheese station and "John" had keyed it into the toppings station. Orders came in from the cashier or online, then went to dough/sauce/cheese, toppings, oven, prep (cutting and garlic crust sauce, dipping addons), then delivery. Of course on things like superbowl Sunday "John" was just the manager keying in every station and deligating orders manually, because that was still slightly faster. But what really impressed me, after a few other years of various fast food jobs, was that it was not tied to any financial incentives. Managers couldn't view the historical data in any way. There were no bonuses or rewards based on it. So there was no reason to lie and send it to a new station screen early. I had worked at Burger King and Taco Bell prior. At both of those locations there was a similar, but simplified system. You keyed in an order as taken. Then as done. Then as served. From what I could tell, management bonuses were based on certain metrics on these times. The burger king actually had a single 8 segment display hanging in the kitchen showing us our current letter grade (A-F) for performance in the past hour. We were told to just key in any order that would take longer than normal as instantly done. Domino's must have had some great data to optimize their kitchens on. While BK and Taco Bell have their kitchens telling them everything is fine, because they will be punished if they say some new specialty sandwich takes too long to prepare.

thaumasiotes 3y ago
> Managers couldn't view the historical data in any way. There were no bonuses or rewards based on it. So there was no reason to lie and send it to a new station screen early. It seems like the system described would be resilient to that? If there were incentives, tracking, and punishment, the process still involves the earlier-stage employee keying the pizza out and then the later-stage employee keying it in. If the earlier-stage guy benefits from lying about how quickly he finishes his stage of the pizza, how does he persuade the later-stage guy to take the fall of incredible slowness by keying the pizza in to his stage early?

LelouBil 3y ago

I tried to order a pizza at a big pizza chain near me, but their website wouldn't take my address! It was one of these autocomplete drop-down but it won't let you enter anything not in the options. I tried calling them but the guy on the phone was also telling me the system wouldn't accept my address! In the end he did the delivery himself since there were not a lot of customers that day and knew the correct address.

zapkyeskrill 3y ago

[flagged]

fukawi2 3y ago

My first job was supporting and developing order related systems for retail and wholesale (separate systems, but we operated both the wholesale and retail operations). Wait until you start having to deal with Forward Orders, Back Orders, Special Orders, Cancelled Orders, and Refunds. Not to mention the General Ledger postings you have to make for each transaction too. An "order" sounds super simple, but there are so many variations and corner cases.

epa 3y ago

Every few quarters a post like this shows up on HN from an engineer who has ventured into sales reporting. Always a good reminder on why project scoping is so important!

vishnugupta 3y ago

This is a great article. IMO engineers and product managers building e-commerce and related systems should at the very least spend a few days at a physical store to observe and document how they work. A great number of engineers are asked to build software in domains for which they have very little idea. For example, Uber engineers would learn a great deal by spending a few days with a driver. They can then place their own system components in context and make sense of it all. Failing to learn domain knowledge has resulted in so many half ass wheels being reinvented.