A guest database and points that earn and redeem, built into the order, not bolted on

Most restaurant loyalty runs as a bolt-on: a separate app your guests have to download, a second login for your staff to babysit, and a points system that never quite agrees with the register. Opero takes the other path. The guest database and a points-based loyalty program live on the same order spine as your POS, kiosk, and QR ordering. Guests earn points on every order and, once you turn redemption on, spend them back as a discount at the register or the self-order kiosk, so a guest's history and their rewards are part of the order, not a sticker on top of it. And it's included from the $149 Opero plan, not sold as a separate module.

What Opero loyalty is, and what it isn't

Opero loyalty is deliberately basic, and we'd rather be straight about that than oversell it. What you get is two things that work together: a customer database (a CRM record for every guest who identifies themselves) and a points-based rewards program tied to it. A guest earns points on what they spend, their visit history and lifetime value accrue on one profile, and, when you enable it, they redeem those points for a discount at the register or the kiosk. That's the whole shape of it: a real guest database and a working earn-and-redeem points program, not a marketing-automation suite.

What it is not, today, is a multi-tier VIP-membership engine or a gift-card system; scheduled email campaigns live in the Marketing suite (included on Opero Full-Service, an add-on on Opero). If your growth plan depends on marketing blasts or tiered membership levels out of the box, Opero isn't that yet. What it does well is quietly build a guest record on every order and reward repeat visits on rules instead of a manager's memory.

Every guest who gives a phone number or email becomes one profile per guest, deduped so the same person isn't split across two records. The profile carries:

• ✓Name, phone, and email, however the guest chose to identify themselves
• ✓First seen and last seen: when they started coming in and when they were last through the door
• ✓Visit count and lifetime value: how often they come and what they've spent, updated on every linked order
• ✓A marketing-consent flag, captured explicitly at opt-in, so you know exactly who agreed to be contacted
• ✓One record per guest per account, so a concurrent double-tap at a busy kiosk can't spawn a duplicate

One guest profile, keyed to the check

The reason any of this holds together is that a guest profile is tied to the order itself. When a guest is identified, their order is stamped with that customer record, so their history isn't a guess reassembled from a pile of receipts later. It's the orders themselves. And because the guest lives on your account rather than on a single register or a single store, that one profile spans your locations: a regular at one location is the same guest at another, on one running history.

• ✓Every identified order links to the guest: history is the orders, not an after-the-fact match
• ✓One profile per guest across all your locations under the account
• ✓Lifetime value and visit count roll up automatically as orders close
• ✓The same order-and-payment spine your POS and payments already run on, so there's nothing to reconcile between systems

Points that earn on the order

The rewards program is points-based and simple: a guest earns points on the order total (one point per dollar by default, and you set the rate), and their balance is shown the moment the order is placed. Every earn is written to a ledger, and the ledger is idempotent: if an order is retried or replayed, the guest is credited once, never twice. You get a clean, auditable points history per guest instead of a balance that drifts every time something reruns behind the scenes.

• ✓Points per dollar on the order total: one per dollar by default, owner-configurable
• ✓Balance shown immediately at checkout, so the guest sees what they just earned
• ✓An idempotent points ledger, with no double-credit on a retry or replay
• ✓Points and history live on the guest profile, per account, alongside their visit and spend record

Points that redeem for a discount

Earning is only half a rewards program. Points have to be worth something. When you turn redemption on, a returning guest at the self-order kiosk enters the same phone number or email they use for their receipt, sees their balance, and applies their points as a discount on the order before they pay. The discount comes off the check like a coupon, and the points are debited from their balance at the same moment. Redemption ships off by default: you enable it from Admin, on your terms, and it stays dark until you do.

It works at the register too, which matters if your dining room is the business. On the settle screen your server looks the guest up by phone or email, sees their balance against this check, and applies the points. The discount spreads across the table's orders, tax recalculates on the discounted amount, and the points come off their balance in the same instant. Remove it and the points go straight back; void the check and they return automatically. A guest who never touches a kiosk still earns on the check when it's paid, so a restaurant with no kiosk at all still has a working rewards program.

You set the terms. Choose what a point is worth (100 points for $5 to start), the minimum balance a guest can redeem, and the largest share of a single order points may cover. A guest can use a coupon or their points on an order, but not both: one discount per order, so the math stays honest. And the money path is built the same careful way as the rest of Opero: the points debit is atomic and idempotent, row-locked so two devices can't spend the same balance twice, and if a balance runs out between the guest tapping 'apply' and the order landing, the order simply stands at the regular price rather than granting a discount with no points behind it.

• ✓Redeem at the register: the server looks the guest up on the check and applies their points
• ✓Redeem at the self-order kiosk: the same contact the guest uses for their receipt pulls up their balance
• ✓Off by default, and you enable redemption from Admin when you're ready
• ✓You set the rate, the minimum redemption, and the max share of an order points can cover
• ✓One discount per order or check: a coupon or points, never stacked
• ✓Atomic, row-locked, idempotent points debit: no double-spend, and never a discount without the points behind it

Guests enroll themselves at the kiosk

On the self-order kiosk, enrollment is the guest's own two seconds: they add a phone number or email at checkout, the screen shows the points they just earned and their new balance, and a receipt is texted or emailed to them. If you've turned redemption on, that same contact also pulls up a returning guest's balance so they can apply their points to the order right there. There's nothing to download and no account to create, which is exactly why guests actually do it. The receipt send is transactional and tied to the payment, so the anonymous kiosk endpoint can't be turned into a spam relay; it's a receipt for a real, paid order, not a marketing message.

Because it's the same self-order kiosk that already takes the order and the payment, capturing the guest costs the operator nothing extra: no clipboard at the counter, no punch cards to reprint, no second device to buy. The guest record and the points are a byproduct of an order you were taking anyway.

Included on every plan, per location

Loyalty and the guest database are included from the $149 per-location Opero plan (the same plan that includes POS, KDS, and QR and web ordering) alongside unlimited devices and no per-device fees. You don't stack a loyalty module on top of a base price; it's part of the plan. Opero Full-Service ($249) and Enterprise (custom) add operations depth on top (table service, inventory and recipe costing, labor scheduling, AI), but the guest database and points program are there on every plan. All plans are per location, month-to-month, with no long-term contract.

How the guest data feeds the rest of the OS

Because the guest database sits on the same spine as everything else, the guest record isn't stranded in a loyalty silo. Orders carry the customer, payments are already matched to those orders, and the AI command center reads the whole picture (which guests come back, what they spend, how a location's repeat business is trending) without exporting a loyalty report and cross-referencing it against sales by hand. One menu spine, one order pipeline, one guest record: that's the point of building loyalty into the operating system instead of bolting it on.