POS Sapaad con: what that search means, and how to sign back in

Somebody in a kitchen wants their point of sale screen back. They start typing the web address, the browser hands the half-finished string to a search engine, and what comes out is pos sapaad con, with con where com should be. People also type sapaad pos and pos sapaad and mean exactly the same thing: let me back into my own account, quickly, because there is a queue.

So the first half of this article is the boring, useful answer to that. The second half is the question sitting underneath it, which is more interesting than it sounds: in a restaurant, which screens should ask anybody to sign in at all?

Getting back in, in the next two minutes

None of this is specific to one brand. It is the same short list for any cloud point of sale.

Use the exact address your installer gave you. Cloud systems often have a general website and a separate login address, and the one you want is usually the second. Typing a guess into a search bar during a rush is how ten seconds becomes ten minutes.

Bookmark it and pin the tab. On the machine at the counter, pin the tab so it reopens by itself after a restart. On phones, save it to the home screen. Do this once, on every device your managers use, and the problem stops happening.

Reset the password through the account that owns the system. Not through a search engine, and not by asking in a group chat. Whoever holds the owner or admin account can send a reset. If nobody knows who that is, that is the real problem and it is worth solving on a quiet morning.

Keep the support route written down somewhere physical. Your provider's support page, your account number and the name of whoever installed the system, on a card by the counter. During a rush, nobody remembers where the email with those details went.

Why this keeps happening

It is not carelessness. It is what happens when the only way into your own business is a web address somebody has to remember under pressure.

Cloud software is defined by being reached over a network from wherever you are. The United States National Institute of Standards and Technology sets out that definition: service you help yourself to on demand, reached over a network, running on shared capacity that flexes with use. That is genuinely useful. It also means the address and the password are the whole wall, so both need to be somewhere better than one person's memory.

There is a second reason, and it is the one worth fixing properly. In a lot of small restaurants everybody signs in as the same person. One account, one password, shared by the owner, two managers and whoever is covering tonight. It works until somebody leaves, or until a price changes and nobody can say who changed it.

Splitting that into a real owner account and separate manager accounts takes about 10 minutes and pays for itself the first time you need to answer the question. It also means a password reset stops being an emergency, because more than one person can send one.

Once you accept that, the next question follows on its own.

Which screens should need a login at all?

A restaurant runs on more screens than most owners count. Sorting them into two piles is a ten minute exercise that changes a Wednesday evening more than the choice of brand ever will.

Screens that must be behind a login. Anything that changes money or data. Ringing a sale. Editing prices. Reading sales reports. Exporting a customer list. Adding or removing staff. These deserve a password, separate owner and manager accounts, and a record of who changed what and when.

Screens that should never ask for one. Anything a customer or a driver touches. A menu. An order. The page that tells somebody where their food is. A loyalty card. A driver marking one delivery done.

Most restaurant frustration lives in the second pile being treated like the first. Every login you put in front of a customer is a chance for them to give up, and every account you create for a driver is one more thing that has to be issued, remembered and removed when they leave.

What that looks like when it is built properly

Get Menu is built on the second half of that split, so it is a fair example of what it looks like when nobody has to sign in unless they must.

The menu asks for nothing. Your storefront lives on a web address of its own, included from the first day, with layouts and colours you choose. A customer opens it from a link or a printed code. No app, no account, no password.

Ordering asks for nothing. The cart takes a name and a number at checkout and that is all. Every line is re-priced from your live menu at that moment, so the price shown is the price charged, and a double tap cannot create a second order.

Following an order asks for nothing. The customer gets a status page for that order with no login attached to it.

The driver asks for nothing. The dispatch message carries a link. One tap marks the order delivered, the customer is told automatically, and the link stops working after that run. No account to create and none to remove when somebody moves on.

The loyalty card asks for nothing. Stamps are added per order automatically, tiers carry their own discounts, and the card sits in Google Wallet on the customer's phone, updating itself, styled in a designer you control. Apple Wallet support is built and is waiting on a certificate, because Apple requires every Wallet pass to be signed with a certificate issued to a developer account. Neither one needs an app installed.

At a table, the code is the login. Each table has its own printed card, produced by a card designer in your colours and sent to you as a print pack. The table number travels with the order, so nobody types it and nobody asks. A whole table can order into one bill from their own phones.

And on the staff side, where a login belongs, there are separate owner and manager accounts and an audit record of who changed what and when.

"The screens a guest touches should never have a password on them. We spent a long time making sure a driver could finish a delivery without an account, because the alternative is issuing logins to people who work three shifts."

— Anzul Aqeel, founder of Get Menu

The rest of the evening, briefly

Two more parts that matter once the login question is settled.

Orders reach your team where they already are. A completed order sends 3 messages: a confirmation to the customer with the delivery estimate you set, a kitchen ticket to the managers' group, and a dispatch note to the riders' group carrying the GPS pin. Nobody signs in to receive any of them, and every message is logged so you can see whether it arrived.

The menu keeps itself honest. Upload it from a spreadsheet in one pass rather than typing item by item. Options and add-ons carry their own prices, and required choices are enforced. Stock counts fall per item and per option as orders come in, so a missing sauce does not remove a whole dish, and at zero the item greys itself out on its own. Delivery adds a GPS pin, a building and unit picked from a list, a fee you set per building, and free delivery above a threshold you choose. Coupons, bundles and ten kinds of upsell sit behind that, with the best single discount always winning so nothing stacks by accident, and invoices carry your own TRN.

Where this does not help you

Plainly, so nobody wastes an afternoon.

Get Menu is not a point of sale system. If your search was about getting back into a register at a counter, this does not replace it. There is no counter terminal, no cash drawer, no card processing and no check splitting at the register, and it does not do recipe costing, purchase orders or payroll.

There are no online payments either. Customers pay cash or through your card machine, at the table or at the door. That means no card numbers are stored anywhere in the system, which is a fair trade for most kitchens in this market and the wrong trade for a few.

It also needs a working connection, because the storefront is a web page. There is no offline mode.

Worth ten minutes on a quiet morning

Two jobs, in this order.

First, fix the thing that brought you here. Write the login address, the account owner and the support route on a card, bookmark the page on every device, and pin the tab at the counter.

Second, count the logins your customers and drivers are currently asked for. Every one of them is friction you are paying for in orders that never got placed.

If you want to see the other approach without a decision, the trial runs 15 days and starts without card details, so nothing is charged by accident. After that it is a flat monthly price with 0% commission on orders. Most kitchens are taking orders the same day, detailed order contents clear themselves automatically after 120 days while sales figures stay, and your customer list exports to a spreadsheet on any day you ask, including your last.

Frequently asked questions

What does pos sapaad con actually mean?

It is almost always a half-typed web address, with con where com should be, sent to a search engine instead of the address bar. The person searching it is trying to reach a point of sale login. The fix is to use the exact login address your installer gave you and bookmark it.

I am locked out of my point of sale during service. What now?

Ask whoever holds the owner or admin account to send a password reset, and use the provider's own support route rather than a search result. Afterwards, write the address and the account owner on a card by the counter so the next person does not have to remember.

Should customers have to create an account to order?

No. A customer ordering food should type a name and a number and nothing else. Every extra step loses orders, and an account is the biggest step of all.

Do drivers need an app or a login?

No. The driver gets a link in the dispatch message, taps once to mark the delivery done, and the link expires after the run. Nothing to install and no account to remove later.

Can customers pay online?

No. Payment is cash or your own card machine, at the table or on delivery, so no card details are held anywhere in the system.