Members — who can sign in to your venue's admin

The Members page is where you say who, by name and email, is allowed to sign in to this venue’s admin app and what they can do once inside. It’s a small page — a single table of humans — but it’s the trust boundary for everything else. Add someone here and the venue’s data opens up to them; revoke them and they’re locked out of the till, the menu, the reports, all of it.

This page is for owners and managers. The kitchen and floor team don’t open it. It’s distinct from the broader employee roster (shifts, time-clock, payroll) — those live on the Roster page and don’t necessarily have an admin login. Members are specifically the people with an email-and-password account that opens this admin dashboard.

What it does

Most kitchens used to manage this in their head — “Marco knows the menu password, Sofia can edit the prices, my brother does the books on Sundays.” That worked when there were three people. It stopped working when staff turned over, when a cashier left for a competitor, when the owner wanted to give the marketing intern access to the social calendar without handing over the keys to the entire restaurant.

The Members page makes that boundary explicit. Every person who can sign in to this venue’s admin is listed in one table. Each row carries their email, their display name and avatar, the role that governs what they can do (Owner, Manager, Cashier, Kitchen, Server, or any custom role you’ve defined on the Roles page), the date they joined, and a Customize button that lets you tweak individual permissions on top of the role for that one person.

The same admin account can be a member of multiple venues — the agency-owner who runs three pizzerias signs in once and sees a switcher between them. Each membership is independent: being Owner at venue A doesn’t grant any access to venue B. Adding someone here only affects this venue.

A separate detail: the same role names are also used by terminal employees — the PIN-only staff who use the till but never the admin dashboard. Edit the Cashier role here and every PIN-only cashier on the venue picks up the change immediately, without a separate setup. The two systems share role definitions but live as separate rosters.

The rule

A role is the default; an override is the exception. Give the marketing intern the Staff role for sane defaults, then add the growth.compose and growth.schedule capabilities as personal grants — don’t invent a custom role for one person.

How to use it

Open Admin → Settings → Members. The page shows everyone currently authorised on this venue, with a header row telling you how many members there are and what your own role is. Owners and managers see the + Add staff, Customize, and Revoke buttons; everyone else sees the list but no edit controls.

Adding someone

Click + Add staff. A small dialog asks for the person’s email address. The system looks them up — and here’s the catch: they must have signed in to the app at least once before you can add them. The reason is technical and benign: until someone signs in with their own email, the system has no account record to attach a role to. If the lookup returns “no user found,” send them to app.bitethemenu.com, ask them to sign in (a magic-link to their email, no password required), and try the lookup again — the moment they’ve signed in, the lookup finds them.

Once found, the dialog shows their name and avatar (if they’ve set one). Pick a role from the dropdown — Staff is the safe default if you’re unsure — and click Add to venue. They appear in the table immediately and gain the role’s capabilities the next time they refresh the admin.

Changing someone’s role

Click the role dropdown on their row in the table and pick a new one. The change is live the moment you select — no save button, no confirmation. The person whose role changed will see the new permissions next time their browser re-fetches (within a few seconds).

Customising one person’s permissions

Click Customize on a row. A modal opens showing every capability the system supports, grouped by domain (Inventory, Recipes, Menus, POS, Kitchen display, Staff, Roster, Growth, and so on). Capabilities that come from the role are checked by default and labelled inherited. Toggle one off to remove it just for this person (it shows as a red “removed” badge); toggle one on that the role doesn’t include to grant it personally (a green “added” badge).

Use this for the exception, not the rule. Marco is normally a cashier but for this month he’s also helping with social posts — grant him growth.compose personally. If you find yourself making the same overrides for three people, that’s a sign you want a new role on the Roles page instead.

The overrides badge on the main row — green +N and red −N — shows at a glance whether a person’s effective permissions diverge from their role.

Revoking someone

Click Revoke on their row. The person is removed from this venue immediately. Their account still exists (they can still sign in to BiteTheMenu the platform), but they no longer see this venue in their switcher. If they’re a member of other venues, those memberships are untouched. Revoking is reversible — add them back with the same email and they’re in again.

Worked example

Anna runs Pizzeria da Anna in Bangkok. She’s the only member to start with — her own email, role Owner. As the team grows she comes back here every few weeks.

First hire: Pim, her front-of-house manager. Anna clicks + Add staff, types pim@pizzeriadaanna.com, the dialog says “no user found.” Anna sends Pim a quick WhatsApp: “go to app.bitethemenu.com and sign in with your work email.” Pim does. Anna runs the lookup again — found. She picks Manager from the dropdown and clicks Add to venue. Pim now has the run of the place: menu, hours, staff, the till, the social calendar — everything except billing and role definitions, which only owners can touch.

Second hire: Mai, the new evening cashier. Add staff, lookup works (Mai signed in this morning), role Cashier. Mai can open and close the till, take orders, process payments. She cannot edit prices, cannot change the menu, cannot see staff or roster.

Third addition: Bea, a marketing freelancer Anna hired for a three-month social push. Anna adds her with the Staff role first — the lowest-trust default — then clicks Customize on Bea’s row. The override modal opens. Anna toggles on growth.compose, growth.schedule, and growth.publish so Bea can draft, schedule, and publish Instagram and Facebook posts. She also toggles on analytics.view so Bea can see whether the posts are working. A green +4 badge appears on Bea’s row. Bea can now do exactly the four things her job needs, nothing else.

Two months in, Bea’s contract ends. Anna clicks Revoke on Bea’s row. Bea disappears from the table; next time she opens the admin, the venue is no longer in her list. Anna’s done in five seconds.

Roles and capabilities — the source of what each role’s defaults are, and where you define custom roles when the standard ones don’t fit.
Audit log — every membership change is logged here with the actor, the target, and the timestamp.
Telegram bot — when a member pairs with the platform bot, their bot capabilities are intersected with their member capabilities, so the bot can never exceed what they’re allowed to do in the admin.