Customers, Credit Balance & Loyalty in Meztezz

Most restaurants know their regulars by face — that couple who always orders the same biryani, the office crew that turns up every Wednesday, the auntie who sits at table 4 every Sunday morning. What most restaurants don’t know is what those regulars are worth: how many times they’ve come this year, how much they’ve spent, whether they’re due a thank-you call, whether they’ve paid the tab they ran two months ago. A customer record is the small piece of admin that turns “I think they’re a regular” into “I know they are, and here’s the number”. This post is about how Meztezz builds that record.

This guide walks through the three things the customer side of Meztezz does — the customer master (the record itself), the Khata (credit balance, for running tabs, with a per-customer credit limit), and the loyalty programme (points earned per rupee spent, with auto-promoted tiers). It picks up after Discounts, Offers, Coupons & Happy Hours — the “loyalty is a payment, not a discount” rule from that post is the single most important thing to keep straight as you read this one.

💡 Where these live in the app. The customer master lives at More → Masters → Customers on the terminal, with inline lookup baked into the billing screen. The Khata (credit) toggle is under Settings → Credit / Khata; the loyalty settings are under Settings → Loyalty. The cloud dashboard mirrors all of this at Reports → Customers and the dedicated Credit page.

The Walkthrough at a Glance

Part	What you’ll learn
1. The Mental Model — Three Reasons to Track a Customer	Why you do it, and what you skip if you don’t.
2. The Customer Master — Phone Is the Key	The fields, the unique identifier, the validation.
3. Adding a Customer at the Counter	The inline lookup-or-create flow during billing.
4. Walk-Ins, Anonymity & When to Skip the Form	Don’t force a record where one doesn’t help.
5. Khata: The Restaurant’s Running Tab	What credit balance is, and why “Khata” is the right word for it.
6. How Credit Gets In — Charging a Bill to Credit	The everyday way a tab grows, and the automatic reversal.
7. How Credit Gets Spent — As a Tender at Settlement	Full-pay, partial-pay, mixed with cash and UPI.
8. Negative Credit Balance — When You Owe the Customer	The intentional case, and why we don’t clamp it to zero.
9. The Customer Details Sheet & Credit Statement	Where you read a customer’s history and settle a tab.
10. Loyalty Points — Earn-As-You-Spend	The rate, the per-bill math, where points show up.
11. Tiers — Bronze, Silver, Gold, Platinum, Auto-Promoted	Lifetime spend, automatic upgrades, multiplier on earn.
12. Redeeming Points — As a Tender, Not a Discount	The single tax-treatment rule and why it matters.
13. Expiry — The Inactivity Clock	How long unused points last and why we expire on inactivity.
14. Loyalty vs Credit — When to Use Which	Two systems, two purposes, easy decision rule.
15. Permissions, Manager PIN & Audit Trail	What gates what, and what the manager has to do.
16. What the Owner Sees on the Cloud Dashboard	The Customers page, the Credit page, what’s there and what isn’t yet.
17. Captain App, Aggregators & Marketing — Where It Doesn’t Reach	Honest limits at the edge of the customer story.
18. Honest List of What Meztezz Doesn’t Do (Yet)	Birthday bonuses, segments, gift cards, SMS — what isn’t there.
19. Habits That Save You Later	Five small disciplines that build a customer book worth having.

Part 1 — The Mental Model — Three Reasons to Track a Customer

There are three reasons to attach a customer record to an order, and they map cleanly to the three systems in this post.

Reason	The system that supports it
You want to know who they are so you can serve them better next time.	The customer master (Part 2).
You don’t want to settle every bill on the spot — a regular runs a tab and pays it down later.	The Khata / credit balance (Parts 5–9).
You want to reward repeat business in a structured, reportable way.	Loyalty points (Parts 10–14).

If none of those three is true for an order, skip the customer record. A casual walk-in lunch from a passer-by is fine as an anonymous order — forcing the cashier to invent a phone number for a one-time guest just clutters your data. The customer system is for people you’re trying to remember; not for everyone who happens to eat.

Part 2 — The Customer Master — Phone Is the Key

A customer record in Meztezz is built around the phone number. Phone is the unique identifier, the primary lookup, and the thing that lets the same person be recognised across visits, devices, and outlets.

2.1 The Fields — `More → Masters → Customers → Add Customer`

Field	Required?	Notes
Phone	Yes	10 digits, must start with 6–9 (Indian mobile range). Stored normalised — no `+91`, no spaces. This is the unique key.
Name	Yes	First and last together; this is what shows on the bill and in reports.
Email	Optional	If supplied, used for receipt forwarding. Not the unique key.
Notes	Optional	Free text — “always wants extra spicy”, “table 4 regular”, “anniversary in November”. This is the field that turns a transactional record into a personal one.
Marketing consent	Optional checkbox	Captured at create. Today we capture it; we don’t yet act on it (no SMS / WhatsApp module is shipped — see Part 17).

2.2 Why Phone, Not Email or Auto-ID

Phone wins in an Indian context for three blunt reasons. Almost everyone has one. People reliably remember their own number when asked. It’s the same number across the year, across visits, across delivery platforms — so the lookup at the counter actually finds them. Email is patchier (half of guests don’t remember which one they gave you), and auto-IDs (Customer #1147) are meaningless to a human who’s about to look someone up at the counter.

The cost of phone-as-key is that you have to enforce the format (Meztezz does this on save). The gain is that the cashier can confidently ask “what’s your number?” and find the same record every time.

Part 3 — Adding a Customer at the Counter

The whole point of phone-as-key is that the cashier doesn’t have to break the billing rhythm to find or create a record.

3.1 Lookup-or-Create — Billing Screen → Customer Field

The billing screen has a customer search input above the cart. The cashier types the phone (or part of the name). The system searches the local customer list and surfaces matches in a dropdown. Three outcomes:

Found — tap to attach. The cart now shows the customer’s name, tier badge, available loyalty points, and credit balance.
Not found, want to add — tap Create Customer. A compact inline form opens with phone (pre-filled from what was typed), name, optional email, and consent checkbox. Save and the new customer is attached to the current order. No detour, no separate trip to a customer screen.
Not found, don’t want to add — close the dropdown. The order stays anonymous.

3.2 Adding Ahead of Time — `More → Masters → Customers → Add Customer`

You can also create customers ahead of time — useful when you’re capturing a guest list for a reservation, importing a list of known regulars, or registering a corporate-account contact who will run a tab. The form is the same as the inline one, with a few extra fields for notes.

3.3 Editing a Customer

Open the customer in More → Masters → Customers, edit, save. Edits sync to the cloud and propagate across outlets if you run multiple. The phone number is locked once the record is saved — the edit form keeps it read-only — because changing the identity of a record with history attached is rarely what you actually want. You edit name, email and notes; the phone stays put.

Part 4 — Walk-Ins, Anonymity & When to Skip the Form

A core piece of restraint in the design of Meztezz: anonymous orders are first-class. If the customer field is empty when the cashier hits Settle, the order is recorded as an anonymous walk-in. Tax is computed, the bill prints, the kitchen sees the KOT, the reports update — everything works.

The cost of skipping the record is that you can’t:

Earn or redeem loyalty points on that bill.
Charge to credit (no one to attach the balance to).
See “this guest’s order history” later.

If none of those matters for this order, skip the customer field. The discipline is “every regular has a record; every walk-in does not”. Mid-shift is the wrong time to be hand-collecting phone numbers from indifferent guests — and a customer list cluttered with 9999999999, 1234567890, and other dummy numbers entered by a hurried cashier is worse than no list at all.

Part 5 — Khata: The Restaurant’s Running Tab

“Khata” is the Hindi-Urdu word for a running account or ledger — the small notebook a corner shop keeps for regulars who pay at the end of the month. Meztezz adopts the word because it’s exactly what the credit-balance feature is: a per-customer ledger that goes up when the customer charges a bill to credit, and goes down when they pay the tab off.

5.1 Turning It On — `Settings → Credit / Khata`

The Khata feature is opt-in per restaurant. Turn the Enable Credit Payments toggle on under Settings → Credit / Khata. With it off, the customer record is purely descriptive — bills can’t be charged to credit. With it on, every customer record gains a balance field and the Credit tender appears at settlement.

The reason it’s opt-in: some restaurants (especially quick-service and walk-in-heavy operations) genuinely have no use for running tabs and prefer the simplicity. Most full-service operations turn it on day one.

The same Settings → Credit / Khata screen carries a Default Credit Limit (seeded at ₹5,000) — the cap a customer’s outstanding tab can reach before the Credit tender is refused. It’s a default, not a hard rule: each customer record can either use the default limit or set a custom limit of its own (a custom limit of ₹0 means “no credit for this customer”). When a credit charge would push the balance past the effective limit, Meztezz rejects it at settlement. More on this in Part 6.

5.2 What’s Different From “Just Letting Someone Pay Later”

A Khata is not “the cashier writes the amount on a piece of paper”. It’s:

A tracked balance per customer — not per visit, not per table — that survives across shifts, days, and (with sync) across outlets.
A real tender in the billing flow — settling with Khata is the same operation as settling with cash or UPI, with the same audit trail.
A reportable item — the dashboard’s Credit page rolls up total outstanding, the top debtors, and per-customer ageing (Part 16).

The discipline is that nothing about a customer’s money happens off-system. Every charge, every payment against the tab, every reversal of a cancelled credit charge, every void is a recorded transaction with a timestamp, a user, and (where required) a manager.

Part 6 — How Credit Gets In — Charging a Bill to Credit

The everyday way a customer’s tab grows is charging a bill to credit at settlement; it comes back down when they pay the tab off, and it reverses automatically if a credit-charged order is later cancelled. There’s also a manager-gated balance-adjustment capability for corrections. Knowing these is most of the operational training.

6.1 Charging a Bill to Credit

The everyday way a tab grows: at settlement, the cashier picks Credit as the tender (covered as a tender in Part 7). Instead of cash or UPI coming into the till, the bill amount is added to the customer’s outstanding balance — the customer is, in effect, agreeing to pay later. The balance goes up by the charged amount, and a charge transaction is recorded against the order.

This is where the credit limit from Part 5 does its job: before the charge is accepted, Meztezz checks the customer’s effective limit (their own custom limit, or the restaurant default if they’re using it). If the new balance would exceed the limit, the charge is rejected and the cashier has to take another tender for the difference. A customer set to a ₹0 limit can’t be charged to credit at all.

6.2 Automatic Reversal of a Cancelled Credit Charge

The other thing that moves a credit balance isn’t a manual action at all. If an order that was charged to credit is later cancelled or voided (covered in detail in Refunds, Cancellations & Edits After Save), Meztezz automatically reverses the credit charge — the amount that was added to the tab comes back off it. The reversal is tagged to the original order and recorded as a reversal transaction, and because the customer may already have paid that tab down, it can legitimately push the balance negative — which is the subject of Part 8.

💡 There is no “refund to credit” tender. When you refund a bill, the refund method choices are Cash, Card, UPI, or “same as the original payment” — you can’t route a refund onto a customer’s credit balance as store credit. The only way a balance goes up is a fresh credit charge (or the manager adjustment below); the only automatic down/negative move is the reversal above.

6.3 Manager Balance Adjustment — a Manager-PIN Capability

When a balance needs correcting outside the normal charge/payment flow — a goodwill credit, fixing a balance that drifted, settling a disputed amount — the intended tool is a manager Balance Adjustment: a signed amount (it can push the balance up or down), gated behind a manager PIN, with a reason, logged with the manager’s name, amount and timestamp. It’s the one path that moves a balance without a bill or a payment behind it.

One honest caveat: this is a manager-gated capability the app references — on a negative-balance account it prompts “Use Balance Adjustment to settle” — but it isn’t yet wired up as a one-tap button in the current terminal build. In practice today a negative balance is usually cleared by letting it net against the customer’s next credit charge (Part 8.3); if you need to zero one out after paying a customer in cash, drop us a line and we’ll sort it.

Part 7 — How Credit Gets Spent — As a Tender at Settlement

Credit, once it’s on a customer’s account, behaves like any other tender at the moment of settlement.

7.1 The Flow — Billing Screen → Settle

With a customer attached to the order, the Settle modal lists every tender — Cash, UPI, Card, Wallet, Credit — and the customer’s available credit balance is shown next to the Credit tile. Three patterns:

Pay the whole bill from credit. Tap Credit, accept the auto-filled full amount, hit Confirm. The balance drops by the bill total; the bill is settled.
Pay part of the bill from credit, part from another tender. Tap Credit, type the credit portion, tap another tender for the rest. The bill closes when the tenders sum to the total.
Pay nothing from credit. Just don’t tap Credit. The balance is unchanged.

7.2 What “Paying from Credit” Actually Does

The order’s payment record shows Credit as one of the tenders, with the amount.
The customer’s credit balance drops by that amount.
A new credit-transaction row is written, with the order ID as the reference (so the statement in Part 9 can show the linkage).
No cash leaves the till for the credit portion — which is the whole point. The cash drawer reflects only the cash tenders.

7.3 What It Doesn’t Do

Credit-as-tender does not affect the GST calculation. Tax is computed on the goods value, the same as it would be for a cash bill. Which tender is used to settle is downstream of tax — they don’t influence each other.
Credit-as-tender does not change how many loyalty points the bill earns. Loyalty earns on the order’s net payable (the bill total after discounts, offers, coupons and any loyalty redemption — see Part 10), not on the mix of tenders used to settle it. Whether the customer pays by cash, UPI, or credit, the points earned are the same — points reflect what the order came to, not how it was paid for.

Part 8 — Negative Credit Balance — When You Owe the Customer

A customer’s credit balance can go negative. A negative number means the restaurant owes the customer money, and Meztezz neither hides it nor clamps it to zero.

8.1 How a Negative Balance Happens

The common path is a credit-paid bill that’s later cancelled or voided, where the reversal is larger than what’s still on the tab. Imagine: a customer with a ₹200 outstanding balance charges a ₹300 bill to credit (balance = +₹500), then pays ₹500 against the tab and clears it (balance = ₹0). The next day, that ₹300 credit-charged order is cancelled — the reversal puts ₹300 back, but there’s no balance left for it to come off, so the balance lands at –₹300. That negative is real: because the customer already settled the tab in full, the restaurant now owes ₹300 back to them. Meztezz logs the reversal and even warns in the background that the balance has gone negative — it does not clamp it to zero.

8.2 Why We Don’t Clamp It

If the system silently clamped negative balances to zero, the customer would lose money quietly. That’s not a software problem — that’s a trust problem. We display the negative honestly so the next time the customer comes in, the cashier sees “balance: –₹100” and can either pay it out or work it off against their next bill.

8.3 What to Do When You See One

A negative balance is a flag, not an error. The practical response:

Confirm with the customer that they’re owed the amount.
The simplest resolution is to let it net against their next bill — their next credit charge eats into the negative first. (Zeroing it out after a cash payout would need the manager Balance Adjustment, which isn’t yet a one-tap action — see Part 6.3.)
If you can’t trace where the negative came from, the Credit Statement (Part 9) is the audit trail — walk through the charges, payments and reversals and one of them will explain it.

On the cloud, a negative balance shows on the Customers page in green (the per-customer balance column flips colour and sign for “owed to customer”), so an owner reviewing the list sees both directions of the ledger.

Part 9 — The Customer Details Sheet & Credit Statement

The customer’s history lives in two related places: the Customer Details sheet (a general at-a-glance view) and a separate Credit Statement sheet (the credit ledger proper). Knowing which is which saves a lot of confusion.

9.1 The Customer Details Sheet

Open a customer’s record (More → Masters → Customers → tap a row) and you land on the Customer Details sheet. The headline is four numbers — Total Orders, Total Spent (lifetime), Loyalty Points, and Last Order (how long ago they last came in). Note that the credit balance is not one of these headline tiles; the credit story has its own sheet (below). Under the four numbers is a Recent Orders list, and a History button next to Loyalty Points opens a separate Loyalty History sub-sheet — the earn/redeem/expire timeline for points.

9.2 The Credit Statement

The credit ledger is a separate, date-ranged Credit Statement sheet (reached from the Credit Settlement flow / the customer’s Khata account). It’s the audit trail for the tab, and unlike the order list it uses Charge and Payment columns rather than a single signed amount:

Column	What it shows
Date	When the transaction happened (with the order number underneath, where there is one).
Type	One of `charge`, `payment`, `reversal`, `adjustment`, `void`.
Charge	Amount added to the balance (e.g. a bill charged to credit, or a positive manager adjustment).
Payment	Amount taken off the balance (a payment against the tab).
Balance	The running balance after that row.

Voided rows are struck through, and a manager can void an eligible entry from this sheet.

9.3 What These Screens Are For

Three uses, in order of frequency:

“How much do I owe you?” — open the Credit Statement; the balance line is right there.
“I think you charged me wrong for that order last month.” — find the order in Recent Orders on the Details sheet, tap through, the original bill opens.
“Where did this negative balance come from?” — scroll the Credit Statement until the reversal (or adjustment) row that flipped the balance negative. The answer is always there.

Between them, these two sheets are where most customer money disputes start and end. Open the Details sheet for “who is this regular and what have they ordered”, and the Credit Statement for “what’s the tab and how did it get here”.

Part 10 — Loyalty Points — Earn-As-You-Spend

Loyalty is the second of the two retention systems in this post. Where Khata is money, loyalty is recognition — a structured way to reward repeat business that’s separate from cash and trackable across visits.

10.1 The Earning Rule — `Settings → Loyalty → Earning Rate`

The rate is points per rupee spent, with a default of 0.1 — i.e., one point for every ₹10 the customer actually pays. The setting is a free-form decimal, so 0.05 (one point per ₹20), 0.2 (one point per ₹5), or any other rate is fine. Most restaurants land between 0.05 and 0.2 depending on how generous they want the programme to be.

Points are earned on the order’s net payable — the grand total after any discount, offer and coupon and after any loyalty redemption, and inclusive of tax, service charge, packaging and VAT. In other words, points are earned on what the customer hands over, not on a pre-tax goods figure. The earning rule, end to end:

net_payable   = grand_total − loyalty_redemption          (grand_total already includes tax & charges, less discounts/offers/coupons)
earned_points = floor( floor(net_payable × earning_rate) × tier_multiplier )

The floor matters — fractional points are dropped rather than rounded, both when applying the rate and again after the tier multiplier. The tier multiplier comes from Part 11.

10.2 Where Points Show Up

At the counter — when a customer is attached to the order, the cart shows their current point balance and tier badge next to their name.
On the bill — printed at the bottom: Loyalty points earned: 47 Total points: 1,283. The guest leaves knowing exactly what the bill added to their account.
On the customer record — the headline section of the Customer Details sheet.
On the cloud dashboard — the Customers page lists every customer’s current points and tier (Part 16).

10.3 Anonymous Orders Don’t Earn

If no customer is attached, no points are earned — and the cashier cannot “save these points for later” or attach them to a customer after settlement. Points belong to the customer at the moment of the bill. This is the most common “why didn’t I get points?” support question, and the answer is always the same: customer wasn’t attached at settle time.

Part 11 — Tiers — Bronze, Silver, Gold, Platinum, Auto-Promoted

Tiers are the structured layer on top of the flat earning rate. Four tiers ship seeded by default, each with a lifetime-spend threshold and an earn-rate multiplier (the values below are the seeded defaults you’ll see under Settings → Loyalty):

Tier	Lifetime spend to enter (default)	Earn multiplier
Bronze	₹0 (every new customer starts here)	1.0×
Silver	₹2,000+	1.25×
Gold	₹8,000+	1.5×
Platinum	₹25,000+	2.0×

11.1 How Promotion Works

Every settled order updates the customer’s total spent — the lifetime sum of their bill totals. When that number crosses a tier threshold, the tier is automatically upgraded in the background; the next bill earns at the new multiplier. The guest doesn’t have to ask; the cashier doesn’t have to do anything; the record updates itself.

11.2 No Demotion

Tiers go up automatically. They don’t come back down. Once a customer has earned Gold by crossing the Gold threshold (₹8,000 lifetime by default), they stay Gold even if they take a year off — and even if a refund pulls some of that spend back. The reason is recognition rather than economics: a customer who reached Gold once was a real Gold-tier customer in the past, and demoting them silently is the kind of “feature” that annoys exactly the customers you most want to keep.

11.3 The Thresholds Are Defaults, Not Law

The four tiers ship seeded with the thresholds and multipliers in the table above, and Settings → Loyalty shows each tier’s name, min-spend and multiplier. Treat the seeded numbers (Silver ₹2,000, Gold ₹8,000, Platinum ₹25,000) as sensible starting points rather than fixed rules — a premium-priced restaurant will reasonably want higher entry points than a neighbourhood diner. Most restaurants find the seeded scheme sensible and leave it alone.

Part 12 — Redeeming Points — As a Tender, Not a Discount

This is the part where Meztezz behaves differently from a lot of off-the-shelf loyalty plugins, and the difference is deliberate and correct.

12.1 The Mechanics — Billing Screen → Settle → Redeem Points

With a customer attached, the Settle modal shows a Redeem Points action. Tap it and you get:

The customer’s available points.
The redemption rate (₹ per point, default 0.1 — i.e., 10 points = ₹1; configurable in Settings → Loyalty).
A slider or number field to pick how many points to redeem.
The maximum redeemable, which is the lesser of:
- The customer’s full point balance.
- The configured cap (default 50 % of the bill total — also editable under Settings → Loyalty → Max Redemption %).

Slide or type, accept, and the redemption appears as a Loyalty line on the bill total area — below the tax lines, not above them.

12.2 Why Below the Tax Lines

This is the rule that matters most for an owner with an accountant. Loyalty redemption is treated as a payment method, not as a discount on the goods. Concretely:

Tax is computed on the full discounted goods value, before the loyalty redemption is subtracted.
The redemption then reduces the customer’s payable total — the cash they hand over goes down by the redeemed amount.
The GST on the bill is the same as it would be if the customer had paid the whole bill in cash.

The legal reason: those loyalty points were earned on prior taxable purchases where tax had already been paid. Treating their redemption as a discount on a new purchase would effectively give tax relief on a prior sale — which Indian GST law doesn’t permit. By plumbing loyalty as a tender instead of a discount, Meztezz keeps every bill (including the redeemed one) defensible.

If you want a refresher on the same rule from the discount side, see Discounts, Offers, Coupons & Happy Hours → Part 12.

12.3 What Redemption Doesn’t Touch

Redemption doesn’t wipe out earning on this bill — a customer can both earn and redeem on the same visit. It does, though, reduce the base the earn is computed on: points are earned on the net payable after the redemption is subtracted (Part 10.1), so you don’t earn fresh points on the value you just paid with old points.
Redemption doesn’t affect the customer’s tier — points have a balance, tier has a lifetime-spend basis. Redeeming points doesn’t reduce the lifetime spent.

Part 13 — Expiry — The Inactivity Clock

Unused points expire. Meztezz uses an inactivity-based expiry policy: a customer’s points expire if they haven’t transacted in a configurable window (default 12 months; the Settings → Loyalty → Points Expiry dropdown offers presets of 6, 12, 18, 24 and 36 months).

The clock resets every time the customer transacts. A customer who comes in monthly will never have points expire on them. A customer who hasn’t been seen in fourteen months (with the default twelve-month window) will see their balance drop to zero when the expiry sweep next runs against their account.

Inactivity-based (rather than absolute-date) expiry matches how most restaurant loyalty programmes are described to customers — “you have to come back at least once a year” reads cleaner than “points earned in May 2026 expire in May 2027 regardless of what else you do”.

There’s no “expiry warning” mechanic today — no automated SMS, no on-bill warning when a guest is approaching expiry. That’s on the roadmap; it isn’t shipped (see Part 18).

Part 14 — Loyalty vs Credit — When to Use Which

A short decision rule, because the two systems often get confused in the early days of a restaurant using Meztezz.

You want…	Use…
To reward repeat business with a small, reportable benefit per visit.	Loyalty. Points earn automatically; redeem to reduce payable; cost to restaurant is a configurable percentage.
To let a regular run a tab and settle weekly / monthly.	Khata. Charge bills to credit; collect payment periodically.
To compensate an unhappy customer without giving cash back.	There’s no store-credit refund tender today — a refund goes back as Cash / Card / UPI (Part 6.2). The “no cash now” lever is a discount or comp on their next visit.
To correct a credit balance outside a bill.	A manager Balance Adjustment is the intended tool (manager-PIN-gated) — though it isn’t yet a one-tap action; see Part 6.3.
To run a points giveaway as part of a marketing campaign.	Points are earned through the normal earn-on-spend rule (Part 10); a manual “grant points” action isn’t exposed in the terminal UI today.

The clean way to think about the two: Khata is money; loyalty is recognition. Money has to balance to the rupee, ties to the cash drawer, and is auditable as accounting. Recognition is a controllable percentage cost that you’ve committed to in advance and that costs you only when the customer actually returns to spend it.

Part 15 — Permissions, Manager PIN & Audit Trail

A quick reference of which customer-side actions require what.

Action	Manager PIN?	Why
Create / edit a customer record	No	Routine; no money moves.
Charge a bill to credit (settle with Credit tender)	No	Routine tender selection; rejected if it would exceed the customer’s credit limit (Part 6.1).
Record a payment against an outstanding tab	No	Routine; real money is coming in and recorded against the balance.
Credit Balance Adjustment (signed ±)	Yes (backend capability — not yet a UI button; Part 6.3)	The one path that moves a balance without a bill or payment behind it.
Void a credit transaction	Yes	Reverses a logged entry; done from the Credit Statement (this one is wired).
Adjust loyalty points (grant / deduct)	Yes (backend capability — not exposed in the terminal UI today)	Manual point adjustment outside the earning rule.
Redeem loyalty at settlement	No	Routine tender; capped by configured max redemption %.
Enable / disable the Khata system	Settings permission	A settings change with wide downstream effect.

Every action above writes an audit-trail entry — user, manager (where used), timestamp, amount, reason text. The Credit Statement and Loyalty History (Part 9) are one view of that trail; the cloud dashboard’s audit log is the other.

Part 16 — What the Owner Sees on the Cloud Dashboard

The owner-side surfaces at app.meztezz.com for the customer story:

16.1 The Customers Page — `Reports → Customers`

A searchable, filterable list of every customer record, with one row per customer, showing:

Name, phone, email
Loyalty tier badge (Bronze / Silver / Gold / Platinum)
Current loyalty points
Current credit balance (shown when credit is enabled and the balance isn’t zero; positive = outstanding from customer, negative = owed to customer, in green)
Total orders (lifetime count)
Total spent (lifetime sum)

Search by name or phone and filter the list. A full per-customer drill-in — order history, loyalty timeline — isn’t on the cloud yet; the terminal’s Customer Details sheet is where that lives (see 16.3).

16.2 The Credit Page — `Credit`

A focused view of credit-balance flow across the customer base:

Total Outstanding — sum of all positive credit balances; what’s “on tab” across the restaurant right now.
Credits Issued and Credits Redeemed — the flow over the selected window.
Unique Customers — how many accounts currently carry a balance.
Outstanding Accounts — the table of who owes what.
Recent Transactions — the latest credit movements across customers.

This is the report most owners open weekly to decide who needs a polite reminder call. Two things it doesn’t break out yet: a dedicated “owed to customers” total (negative balances show on the Customers page instead) and ageing buckets (current / 1–30 / 31–60 / 60+) — for ageing today, the terminal’s Credit Statement carries the per-transaction dates.

16.3 What Isn’t on the Dashboard Yet

A few owner-visible loyalty pieces aren’t surfaced on the cloud yet, even though the data is synced and available:

Per-customer loyalty history (the earn-and-redeem timeline). The terminal’s Loyalty History sub-sheet has this; the cloud’s customer detail page doesn’t yet break out the loyalty transactions separately.
Loyalty-programme-level KPIs (total points earned this month, total redeemed, redemption rate as a percentage of programme value). The data is there; the report screen isn’t.

These will land in subsequent dashboard updates. If you need the breakdown today, the terminal’s Loyalty History sub-sheet (for points) and Credit Statement (for the tab) are the source.

Part 17 — Captain App, Aggregators & Marketing — Where It Doesn’t Reach

Three places the customer story does not extend today, by design or by sequencing.

17.1 The Captain App

The captain app — the tablet captains use on the floor (covered tangentially in Managing Tables & Reservations) — does not currently carry customer-side features. A captain can take orders to a table, but cannot attach a customer record, view a customer’s points, or apply a credit-balance tender. All customer attachment happens at the main billing terminal when the bill is being settled.

The reason is partly architectural (the captain app is intentionally thin) and partly operational (loyalty and credit are settlement-time decisions, not order-time ones). If you need a captain to attach a customer mid-meal, the workflow today is: tell the cashier who’s at table 5, and the cashier attaches them when the bill comes up.

17.2 Aggregator Orders

Orders coming in from Zomato, Swiggy, and other aggregators currently flow as anonymous orders from Meztezz’s point of view. The aggregator owns the customer relationship; Meztezz sees the order, the items, the platform-discounted price. Loyalty points are not awarded for aggregator orders (the customer record doesn’t exist on the Meztezz side), and credit balances aren’t relevant (the aggregator handles payment).

If a customer who ordered via an aggregator later walks in and you want to recognise them as a regular, that’s a manual capture at the counter — same as any new walk-in.

The customer record captures a marketing-consent flag. There is no SMS / WhatsApp / email marketing module in Meztezz today. The data is captured (so consent is on record from day one), but the act of sending — birthday wishes, festival offers, “we miss you” nudges — isn’t shipped. When that module lands, the consent flag is what governs eligibility.

If you have an existing tool (a Mailchimp / WhatsApp marketing platform) and want to work the consenting-customer list, you’d assemble it from the customer master by hand for now — a one-click CSV export of customers from the dashboard isn’t there yet.

Part 18 — Honest List of What Meztezz Doesn’t Do (Yet)

So you don’t build a customer-engagement plan around features that aren’t there:

No birthday / anniversary bonuses. There’s no birthday field on the customer record, and no automated mechanic to award bonus points or offers on a date.
No customer segments or tags. A customer is one record; you can’t group regulars into “weekday lunch”, “weekend brunch”, “corporate accounts” and treat each segment differently.
No referral mechanic. “Refer a friend, both get points” isn’t a first-class flow.
No gift cards. A pre-purchased balance redeemable by anyone (i.e., not tied to one customer’s phone) isn’t supported — Khata is per-customer, not per-card.
No store-credit refund tender. A refund goes back as Cash / Card / UPI; you can’t route it onto a customer’s Khata balance as store credit (Part 6.2). Relatedly, the manager Balance Adjustment and the manual “grant loyalty points” capabilities exist in the backend but aren’t yet wired as buttons in the terminal UI.
No SMS / WhatsApp / email marketing module. Consent is captured; sending isn’t shipped (Part 17).
No automated expiry warnings. Points expire on the inactivity rule; the customer isn’t notified before it happens.
No multi-customer per bill. A bill is attached to at most one customer record. If two friends split a bill and both want to earn points, the bill belongs to one of them in Meztezz’s eyes.
No captain-app customer attachment. All customer attachment happens on the main billing terminal at settlement time.
No aggregator customer recognition. Aggregator orders are anonymous from Meztezz’s perspective.
No loyalty-history view on the cloud dashboard. Per-customer loyalty transactions are visible on the terminal’s Loyalty History sub-sheet; the cloud’s per-customer drill-in doesn’t yet break loyalty out separately.

Part 19 — Habits That Save You Later

Five disciplines that turn the customer side from a checkbox into a useful asset.

Don’t pad the customer list with dummy records. Walk-ins stay anonymous. A list of 4,000 customers where 1,200 are 9999999999 is a list you can’t trust.
Use the notes field. “Daughter allergic to peanuts”, “always table 12 on Sundays”, “celebrating 20th anniversary in November”. These are the details that make a regular feel known. The cashier reads them on attach.
Run the Credit page weekly and call the top three debtors. Polite, brief, before-it-becomes-awkward. A two-week-old tab is an easy conversation; a six-month-old one isn’t.
Set the loyalty earning rate intentionally and don’t fiddle with it. A rate that bounces between 0.05 and 0.2 across months is harder for guests to trust than a flat 0.1 that just works.
Review the customer list quarterly for inactive Gold-tier customers. Anyone who reached Gold and then went quiet is exactly the customer to call. The tier is the prompt; the phone call is the work.

If any of this didn’t behave the way the guide describes — a customer who can’t be found by phone you swear is registered, a credit balance that doesn’t match the statement, loyalty points that earned the wrong amount, a redemption that hit the wrong line on the bill, or a Gold tier that auto-promoted at the wrong threshold — drop us a line at bazimat@gmail.com or contact us. Tell us which Part you’re on and what you’re seeing; we’ll usually have you sorted in a single back-and-forth.

Once the customer side is humming, the next chapter is the one most owners say they “should be reading” but never do: Reports That Actually Tell You Something — which report to open daily, which weekly, which monthly, what each column means, and the difference between the terminal’s reports and the cloud dashboard. We’ll publish that one next. 🎉