01Ideas that get collapsed into one word
Dohos's access policy insists on keeping several ideas distinct that a simpler system might blur together:
- Identity. who or what is authenticated — a signed-in person, or a service account making an automated request.
- Affiliation. the relationship between that identity and a restaurant or location — which account they actually belong to.
- Role. the approved function that identity performs — owner, manager, staff, or Dohos administrator.
- Permission. the specific technical capability a role is granted — what a screen or an action actually allows.
- Authority. the legal or business power to view a piece of data or direct an action, which authentication alone does not prove.
Being signed in proves identity. It does not, by itself, prove that the signed-in person owns the restaurant they're asking about, has the authority to issue a refund, or should see a caller's phone number. Dohos's policy requires each of those to be checked on its own terms rather than inferred from a successful login.
02The roles the product defines
| ROLE | SCOPE |
|---|---|
| Restaurant owner | Manages the restaurant and location profile, onboarding, menu, availability, policies, voice, team, escalation, billing, usage, analytics, calls, orders, and activation-related settings. |
| Restaurant manager | Runs daily operations — exceptions, current wait, availability, orders, calls, callbacks, relevant menu changes, staff assignment, notifications, operational analytics. Subscription ownership and destructive account actions can be restricted to the owner. |
| Restaurant staff | Uses the operational staff screen — new and changed orders, ticket details, fulfillment updates, availability changes the restaurant permits, current wait, alert acknowledgement. Does not automatically get billing, configuration, customer-history, or transcript access. |
| Dohos internal administrator | Reviews access requests, issues and revokes invitations, assists onboarding, activates or suspends locations, supports phone and provider setup, reviews failures, manages commercial configuration. Explicit and scoped, not a standing, unrestricted path into a restaurant's account. |
That last row is a direct product requirement, not a policy aspiration: Dohos's own build specification states plainly that internal access "must be explicit and scoped" and warns against building "an invisible unrestricted customer impersonation path." A Dohos employee does not get a backdoor into every restaurant's account by virtue of working at Dohos.
03How access is granted, and how it ends
Dohos's policy calls for deny-by-default access: a role gets only what its actual job requires, granted explicitly rather than inherited by default, with multifactor authentication for anyone with elevated or privileged access. Access is meant to be provisioned when someone joins a team that needs it, and revoked the same day they leave it or change roles — not left to expire on a schedule.
High-risk actions get an extra step under this policy: a merchant-account connection, an owner transfer, a bulk data export, activating call recording. Those are meant to require step-up verification and, where appropriate, more than one person's sign-off, rather than the same single click that changes a restaurant's hours.
04Support access
When Dohos support needs to look at a specific restaurant's account to help with an issue, that access is meant to have a defined reason, a specific scope, a time limit, and a record of who did it and when — not silent, unrestricted impersonation. An action taken during a support session should remain attributable to the support person who took it, not appear as if the restaurant did it themselves.
05Emergency access
A genuine emergency — an active incident that needs an immediate fix — is the one case where Dohos's policy allows access outside the normal request-and-approval path. Even then, it's designed to require strong authentication, a defined and narrow scope tied to the actual emergency, someone other than the person using the access being notified independently, an automatic expiry rather than standing access that quietly continues after the emergency ends, and a full record reviewed afterward. It's still not a path around the rule that keeps a card number out of Dohos's systems, or around a tenant boundary, or around a legal hold on specific records.
06Review
Dohos's policy calls for periodic review of privileged and sensitive access, and prompt review after a role, organizational, or incident-driven change — checking actual use, not rubber-stamping a bulk "approve all" list. This is a policy commitment describing the target cadence; it is not a claim that a specific review has already taken place on a specific date.