Hacker News Reader

Comment by Doches | Hacker News Reader

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.

View on HN

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.

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.

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.

If it's too hard to detect, management doesn't have much choice.

It would be smarter for that feature to require a manager's key, and then the manager could actively monitor the situation. But since the manager can't implement that feature, they have to work with what they have.

It read like they DID know how to spot it, and the reaction was... "never again for anyone under any circumstances".

Blanket bans like the one described are always wrong. ;)

If there's a problem, monitor it after every shift, or every day, or weekly. You know who worked what registers; monitor/scan/review, then take action against the offenders.

I worked food service with POS; we had to review things every drawer change, and discrepancies were noted. Repeated discrepancies (either money or between food usage and money) would be tied to someone (or multiple people) and action was taken. It's not always that hard, just a bit time consuming, but... it's part of the job (or was for me).

It's incredibly easy to detect.

Solving personnel problems with policy is unfortunately common at companies in the small-medium space. Very small companies tend to be more person oriented, and very large companies tend to have outgrown it (though they may still do it at the department level).

It is also one of the most annoying mistakes I see frequently repeated at startups and young businesses.

Solving problems with policy is common in all companies. It’s programming at the organisation level. Every policy is either a good candidate for automation or an indication of automation limitations.

Presumably suspend your partner in crimes transaction receipt is printed walk away. Partner slips you some money later.

Solution: don't hire scummy people, pay enough that you can afford decent folks, watch for a friend that always comes to a certain cashier especially while alone, watch for cashier being nervous when observed, watch for partner to break off transaction if observed, "forget card", or return goods shortly.

It's also obviously trivial to catch with the receipt but they will probably refuse to show it. A transaction log will also trivially show it if matched with register and time.

Anyone could potentially get away with this once but any dishonest person is going to want to do this repeatedly.

There is basically no excuse for not catching this as a manager and I see no reason to deny associates this useful feature.

The cashiers would 'fake' the completion and instead just suspend the transaction.

Management didn't bother checking for unusual rates of suspended transactions nor 'check off' on abandoned transactions.

It's almost always a management failure, as it's most likely they just didn't want to do the work instead of wasting time hitting on the inappropriately young employees...

Shouln't that be easy to spot if the items are never returned and inventory doesn't match up? You'd think any abandoned transactions would require signoff by someone else that the items were actually returned (or trashed if perished).

As I said, management is lazy and would rather engage in inappropriate conduct than try to actually do a good job.

The store I managed had a suspend/recall. Cart full of groceries only to realize you left your wallet (at home, in the car, whatever) suspend the transaction and print a slip with a barcode on it. Move the cart out of the way and take the next customer. The customer comes back and scans the slip at any register to recall the transaction, pay and collect their cart and leave without having to hold up lines/etc... Was a nice convenience many appreciated.

This very thing happened to me, and I was very pleasantly surprised with how this worked. It definitely took some of the embarrassment away from being a dolt

I worked at a store that had this feature except if you reloaded the transaction on a different register it still got attributed to the originating register and caused a headache at closing :(

Manual probably dictated that a policy of receipt transfer and (irrationally) presumed synchronous cash out times.

Management just didn't RTFM/FTFM.

When I was studying (late 00s) I worked at a large supermarket chain in the UK that had this. The system was surprisingly well designed.

It was based on Windows NT (somehow hardened, as I never saw a checkout show a BSOD or fail to boot) and was designed before a time when you had a continuous internet connection. There was a mini-server in the back office, and every night it would sync with HQ.

This meant all functionality, including taking credit card payments and loyalty, could be done offline. One time we had a electrical systems failure in the store, and everything - including chillers - went down. However each checkout had its own UPS and continued to operate without issue.

If, let's just say, every little (feature of the checkout software) helps — if you follow my drift — the architect of that system is a mate of mine. I've never worked with him (I know him through music stuff, not tech stuff), but he's a deeply thoughtful guy.

In the store I worked in, which was a notable spot for people attempting credit card/gift card fraud and/or theft, the manager literally just gave me the override code because it happened so often I'd have him coming over like every 15 minutes to cancel something. We were also a super busy store at the same time as this so it would just leave a bunch of hyper-angry customers in line.

Do you know how the gift cards integrate with your POS system ? Do each provider have an API that was called to activate a card or was there something more centralized?

Not sure, this was like 10 years ago at this point and I didn't really pay attention to these details at that time.

Open loop cards just hit the usual network rails.

Closed loop cards are integrated between the POS backend and the program manager. Some large merchants manage their own card programs.

The psychology of this is funny. The right thing with such a POS is to have customer pay for everything so far, move their cart to the side, let them run and get their item, and then let them be front of line at that point to finish their full set of purchases.

99% of the stores I've ever seen don't have checkout aisles wide enough to allow this.

No, I meant, purchase, move cart beyond checkout area in front of cashier.

I guess there is fear their purchased goods might be stolen.

Honestly, to add on to what you said, it's amazing about the lack of domain knowledge that developers and product owners have in making systems for people.

For the clerks and workers using the POS, it's often more of a hinderence than it is a help. When you look at less technically reliant societies (i.e. market places in Asia) you'll see this more often. Prices are negotiated, they can be their own warehouse, smaller companies work together (your package getting from maker, middleman, aliexpress to your door is incredibly complex but they can make it happen within 2-3 weeks).

Isn’t the reason rather that management will say: Is this absolutely necessary and will it increase sales?

And often the answer is no unless you can demonstrate the time gain and emotion of your customer. When the margins are super thight anything that won’t help margings is left away and home delivery /online shopping will be prioritised for the tech team/budget.

Of course they'll say no. It presents a version of the technology that is not commonly done. Justification for their stubborn resistance to support the customer and the users is not relivant here.

We're still stuck filling out forms and passing validation to complete transactions.

My complaint here is that arrogance that POs and devs have in how humans operate with the software is way off. What happens if you want to buy out Aldi's entire stock of brie? Is it reasonable that you should be paying stockprice*quantity? (The answer outside of technology enforced rules is no.. Additionally to aldi corp, theres no reason not to offer a discount here) [Also, in practice they try to hack their way arround it by overriding the price]

The thing a smart manager will ask is "does this open up new avenues for theft/scams". I suspect that it does, unless there is a shit ton of auditing in place.

At scale yes. In realistic common edge case scenarios that don't involve demotivated and exploitive businesses, no.

It's always much faster to check out with a couple of things in a New York bodega/deli, even while making small talk with the clerk, than to check out with the same items at the chain drugstore down the street.

I always like to say something meaningful before plugging my project, but that's exactly why I started working on https://notionsmith.ai

Overall I'm really excited about LLMs being integrated deeper into product development, there are a lot of insights already captured in their output that people building products could use

This is awesome have you posted it to HN yet?

I see that you have a month ago. Anyways I think it’s great, wondering what it costs you to run it for free

Glad someone liked it! :)

It's currently ~$100 a month, I'm working on a paid version but a lot of my users ended up being people BRIC countries so I don't mind footing the bill if they find it useful

To be fair, though, the "customers" aren't the customers. In modern software companies, you don't sell products to be profitable, you sell them to be plausible. As a software company, your value to a venture investor is much greater than it could possibly be to a potential customer. The objective of the startup is to look plausible until the current round of investors sells their stake to the next round of investors. Part of they way those investors value the company is whether or not they think they can sell the company to a greater set of fools.

In the modern software company there is only one customer, the next early stage investor. I can assure you, your execs know how to pitch to them, otherwise they wouldn't have received their A round.

I maintained a POS for a large retail chain - and the variety of transactions that it could handle was far narrower and less subtle than the type of trades that I witnessed working at a weekend open air market.

At the market there was all sorts of bartering and swapping and deal making - my “business analyst” brain recognised that to model all the “transactions” occurring at a typical market would be super complex.

However… the large retail chain should not support subtle/overlapping transactions of that sort- not because it’s too complex to model, even if it was free to model it, make the software track it — the reason the retail chain would avoid it is: profit margin.

You do profitable things, you do them a lot, and you don’t pay the opportunity cost of doing less profitable things. That’s the open secret of successful retail. And small businesses everywhere do not internalise this.

I was really impressed when the cashier at my neighborhood supermarket recently transferred my order in progress over to an empty lane so that I could deal with a credit card issue without delaying the people behind me. Seems like an obvious function but it had never even occurred to me!

I maintained a POS for a retail chain for a few years.

Our suspend/resume sale feature assumed that a suspended sale could only be resumed on the machine that suspended it. Then we had to change it to be resumable on any machine in the store. But only show a flashing notification that there’s a suspended sale, on the original machine.

(Thanks for storing that knowledge for me for the last decade, neurons. I doubt you’ll be asked to recall it again.)

Why only the light on the original machine? Why bother showing the light at all?

Real answer: that’s what the client wanted.

> why bother showing the light at all?

Probably so that the operator can more easily find the suspended sale in order to resume it. Suspend / resume happens rarely enough that operators aren’t fluent with that feature.

> why only the light on the original machine?

Because it’s far more likely that the original machine is the one on which it will be resumed, say 500 times more likely. So that’s 99.8 of the time you’re not alerting a second machine unnecessarily - and if there’s three or four machines it goes into more nines of false alerts being avoided.

But the sufficient answer is - the customer wanted that.

Everyone in the retail chain had experience as an operator (self included) so the user experience decisions were generally well grounded.

> ...let clerks pause sales and put them off to one side...

I dreamed about just such a feature when I worked at a convenience store back in high school. That was 30 years ago. Such progress... >sigh<

>And that's not even _starting_ on the nonsense and bizarre home-rolled systems that small businesses concoct around layaways.

There are a number of things that even many just modestly-paid developers don't grok because they obviously make no sense.

Many years ago I remember asking a then-gf why such and such a store customer service accepted utility payments. And she was "Umm. Some people don't have checking accounts." Layaways are different but in the same general category.

That's a bit like opening a tab in a bar, isn't it?

I think it depends a lot in the country or the business, in some places is so easy, but in others is so difficult.

I remember at least 20 years ago, in the grocery store with the most basic digital scales, every clerk would have their "tab", shared between all the scales. So each one could use the scale nearest to the fruit they were weighing in that moment, then switch to a different one... And finally print the whole ticket without interfering with the other clerks.

Something like this... https://cdn.wallapop.com/images/10420/5j/p7/__/c10420p335420...

We called that feature "parking" the invoice. It's pretty standard on every good POS system.

It can also become a challenge if you have a lot of those and want to find the right one. We had some users that prepared a lot of orders in advance into bags, so they can hand them to the customers right away when they come. Best solution was to print a delivery note for every order, attach them to the bag and then scan a barcode on the bag when the customer comes for pick up/payment. And you also need to be able to add or remove items before the customer pays, people often change their mind.

Reply on news.ycombinator.com