Question 1

A diner says they paid and the money never reached me. What happens?

Accepted Answer

The first thing to know is the thing most people assume, and it is not true here: the money never came to us. It went from the diner's payment app to your bank, directly. There is no payment of yours sitting in our account waiting to be released, because there is no account of ours it could sit in. That means the failure people picture — the platform took the money and did not pass the order on — cannot happen here. There is no step in the flow where we hold it, so there is no step where we can lose it, delay it, or send it somewhere else. What the platform holds is a record of what each side said, and when. A diner tapping “I've paid” is that diner's own statement; marking an order received is yours. Neither one is us confirming that money moved — we have no way to check with a bank, and we never claim to have checked. When the two of you disagree, the order is recorded as disputed. That is a neutral note that you disagree. It is not a finding about who is right, and we do not investigate, mediate, or take a side. If money genuinely left a diner's account and did not arrive, that is a matter for their own payment app or bank under their reversal rules. You decide, as you always have, whether to serve, to ask for payment again, or to write it off. Terms §8 sets all of this out in full.

Question 2

Do you take a cut of my orders?

Accepted Answer

No. Not a percentage, not a per-order fee, and no booking fee charged to your diner. One subscription is the whole price. The subscription is priced by how many tables you have — never by orders, diners, or scans. A busy Saturday costs you exactly what a quiet Tuesday costs. We take no commission and no share of any order, and the reason is structural rather than generous: no money passes through us, so there is nothing to take a cut of. You keep your existing payment method and your existing rates — your own payment QR, or cash and card at the counter. We do not sit between you and your payment provider, so we could not change what they charge you even if we wanted to.

Question 3

Do you ever need my PIN, OTP, or bank login?

Accepted Answer

No, and no screen in the product has a field for one. We never ask for, store, or transmit a UPI PIN, a one-time code, a card number, or a bank credential. We do not need them. Diners pay you on your own payment QR, which you supply — we show what you gave us and never touch the transaction itself. We will never ask you for your password or a one-time code either — not by email, not by phone, not on WhatsApp. We only ever write to you from @tabemi.com. Treat that as an anti-phishing rule you can rely on: anyone contacting you as us and asking for a code is not us, however convincing the message looks.

Question 4

What happens if the platform goes down in the middle of dinner service?

Accepted Answer

You keep serving. This is the part worth understanding before you need it, because it is what makes an outage an inconvenience rather than an emergency. Take orders the way restaurants did before any of this existed — on paper, or spoken to the kitchen. Nothing about your kitchen, your staff, or your ability to serve depends on us being reachable. You still get paid, in full, at the table. Diners pay you directly on your own payment QR or in cash at the counter, and that QR is yours: it works whether or not we do. No payment is stuck in transit, because there is no transit. When we come back, the order board comes back with the orders that were already on it. Orders you took on paper during the gap are yours to enter afterwards or to leave out entirely — nothing syncs them for you, and a night the platform did not see is a gap in the record, not a lost service. And we tell you. When we know something is wrong we say so on the site itself, in plain words at the top of the page, rather than leaving you to work out whether the problem is you or us.

Question 5

What if my internet drops, or a diner has no signal?

Accepted Answer

Then that device cannot reach us, the same as with any website. It is worth planning for honestly rather than discovering it on a busy evening. Diners order in their phone browser on their own mobile data, so one guest's bad signal is one guest, not your whole room. Anyone without data orders from a waiter, exactly as they would have before. The order board does need a connection. If the restaurant's own connection drops, a phone on mobile data stands in for it — the board is a web page, not an installed system tied to one machine in the back office. And the fallback above still sits underneath all of it: paper, and your own payment QR, neither of which needs our service or yours.

Question 6

Do you promise an uptime figure, or a guaranteed response time?

Accepted Answer

No. There is no service-level agreement here, no uptime percentage, and no credit scheme — and we would rather tell you that plainly than print a number we could not always honour. Plenty of services publish something like 99.9% because it reassures. Printing a figure would not make the service any steadier, and committing to one we could not keep would be a worse thing to do to you than saying nothing at all. What we do instead is specific and written down: more than one copy of the app running at any time, releases that put the previous version back by themselves if their checks fail, and nightly backups we restore on a schedule to prove they work rather than assuming they would. Our reliability page lists them. The reason we can afford to be this blunt is the answer above: your restaurant does not stop when we do. That is a better guarantee than a percentage, because it does not depend on us keeping a promise.

Question 7

Something is wrong on a Saturday night. What actually happens?

Accepted Answer

Here is what happens every time, which is a more useful thing to know than a promise about speed we might not keep. Your message is saved the moment it arrives, a copy comes straight back to your inbox so you know it landed, and it is read by a person rather than sorted by a bot. Support hours are not service hours. Your dining room never waits on an answer from us: orders, payments and the live board keep running whether or not anyone is at the inbox. There are five published addresses split by purpose — general support, sales, privacy, legal and security — so an urgent question does not queue behind a sales enquiry. There is no ticket to chase and no triage tier: a problem that stops a restaurant taking orders is the most important thing happening here that day.

Question 8

Is this a POS? Does it replace my billing system?

Accepted Answer

No. It is an ordering layer. Diners order at the table and the orders arrive on your board; billing, accounting and inventory stay wherever they are today. What it replaces is the walk to the table with a notepad, the “we'll be right with you” at a full room, and the re-keying of an order somebody scribbled down. What it does not do is print your bill or keep your books. It does handle the parts of an order a notepad cannot: item prices, taxes and service charges as you have configured them, and a running total the diner sees before they commit to ordering. If you need a POS, keep the one you have. This is built to sit alongside it, not to be it.

Question 9

Does it connect to my POS or my kitchen printer?

Accepted Answer

Not today. There is no POS integration and no kitchen-printer integration, and you should weigh that before you decide. In practice orders arrive on a screen — a phone, a tablet, or the computer already at your counter. If your kitchen works from printed tickets, somebody still puts the order into your existing system. For a kitchen that already works from a screen, that costs nothing. For a busy kitchen built around printed tickets and a POS, it is real double entry, and we would rather you knew that now than found out in week two. It is also the honest reason to trial this on a few tables before committing the whole room to it.

Question 10

I change a price or mark a dish sold out. When do diners see it?

Accepted Answer

There is one menu — the one in the app — so there is no second copy to keep in step and nothing to re-publish. The next diner to open it sees the change. A phone already sitting on the menu picks the change up shortly afterwards on its own, and again whenever the diner comes back to the tab. More usefully, none of that depends on caching. Every order is priced by the server from the live menu at the moment it is placed, so a diner on a stale page cannot lock in yesterday's price. Availability works the same way: an item you mark unavailable is refused at order time, not merely hidden from the list. The kitchen runs out, you mark it out, and the room can no longer order it — including anyone who already had it on screen.

Question 11

Can guests still order from a waiter?

Accepted Answer

Yes, and many will. QR ordering is an option on the table, not a replacement for service, and nothing in the product requires an order to start with a scan. Families, larger groups and guests who would simply rather talk to a person carry on exactly as before. Nothing about the room changes for them. The ones who do use it are not stopped at a signup screen either — diners order as guests, with no account, no phone number and no app to install. In practice it takes the pressure off the moments that actually hurt: a full room at eight, or one server covering more tables than they should be.

Question 12

If I print QR codes now, will I have to reprint them?

Accepted Answer

Not for anything you do inside the app. A QR code printed today keeps working. Rename a table, renumber it, rearrange the room, rebuild the menu from scratch — the printed code does not change. It is a stable code of its own, deliberately decoupled from the label you edit. That was a design decision made specifically so that the cost of changing your mind is never a reprint run. If you leave the platform, those particular codes stop pointing at an ordering page, as any vendor's would. What we can promise is that nothing we do, and nothing you do in the app, makes them obsolete while you are with us.

Question 13

Can I get my data out?

Accepted Answer

Yes — ask us and we will send you a copy. Being straight about the mechanism: there is no self-serve export button in the dashboard today, so it is a request to a person rather than a download. It covers your menu, your orders and your settings — the things it would genuinely cost you to lose. Write to the privacy address on our contact page and say what you want. There is no exit interview and no retention call. We would rather say “ask us” and mean it than advertise a download button that does not exist. When self-serve export ships, this answer changes.

Question 14

Am I locked in? How long is the contract?

Accepted Answer

There is no lock-in and no minimum term. Ask us to close your account at any time and we will close it. As with the export above, closing an account is a request to a person rather than a button in the dashboard today. It is a request that gets actioned, not a retention funnel. There is no exit fee, no notice period, and no penalty for leaving in the middle of anything. The one commitment running the other way is ours: a Founding Partner rate is a contract term rather than a discount we can withdraw, so the rate you start on is the rate you keep.

Question 15

What if you shut down?

Accepted Answer

You get advance notice and a copy of your data. That is written into the Terms as a commitment, not offered here as a good intention — a promise that lives only on a page we can quietly edit is not a promise. If we ever have to stop operating, we tell you in advance rather than turning the lights off, and you get a copy of your menu, your orders and your settings. The practical reason this costs you less here than it would elsewhere: your payment arrangements were never ours to begin with. Your payment QR, your bank, your rates and your relationship with your diners all survive us completely. What is left is a printed QR code and a menu you already have a copy of. We would rather you knew the shape of the worst case than had to guess at it.

Question 16

Do you market to my diners?

Accepted Answer

No. We are not a marketplace, we do not run a consumer app, and there is no surface anywhere in the product that markets anything to the people who eat at your restaurant. We do not email your diners offers, we do not advertise other restaurants to them, and we do not rank you against anyone. There is no such feature to switch off, because there is none to switch on. Your diners are yours. That is a positioning decision as much as a policy — a platform that owns the customer relationship is a different business from this one, and it is the business we deliberately did not build. Diners order as guests by default: no account, no phone number, and nothing collected as the price of ordering dinner.

Question 17

What happens to my diners' data?

Accepted Answer

As little as we can manage, and we would rather give you the specifics than assert that we take privacy seriously. Analytics identifiers are hashed with a per-deployment salt, so no raw addresses are kept. Measurement is consent-gated where the law requires it, Global Privacy Control is honoured, and withdrawing consent takes effect immediately and discards anything not yet sent. Operational logs are deleted after 30 days. A guest's order history stays on their own phone unless they choose to link an account and carry it across devices. The privacy policy has the rest.

Question 18

Who actually runs this?

Accepted Answer

Tabemi is a product of Kordavel, a sole proprietorship based in India. Its business address is published on our contact page, in the Terms and in the privacy policy — the same address in all three, which is what makes it checkable. There are five published contact addresses by purpose — general support, sales, privacy, legal and security — and a vulnerability-disclosure policy carrying a safe-harbour promise for good-faith researchers. It is a small operation. We would rather you weighed that with the facts in front of you than discovered it later, which is why the things a small operation is genuinely bad at — an overnight rota, a formal service-level agreement — are refused above rather than fudged. What it is good at: a problem that stops a restaurant taking orders is the most important thing happening here that day, and the person who reads your email is the person who can fix it.

Everything worth asking before you run a dining room on this.

Money