Skip to content

Legal

Privacy Policy

AM | PM is built for strict multi-tenant isolation, auditable operations, and calm POS workflows. This policy describes — in plain language — what we collect, how we separate venue data, and how we align with the Kenya Data Protection Act, 2019 and solid engineering practice.

Your night out shouldn't come with mystery data practices; here is how we treat information.

Effective date:

1. Who we are & scope

This Privacy Policy applies to the AM | PM platform (POS, admin, reporting, and related surfaces) and to the AM | PM Lounge marketing website where we describe our venue and services.

Depending on context, we act as a data controller for our own website analytics and communications, and as a data processor (or sub-processor) on behalf of venue operators ("Tenants") for operational data they enter into the platform. Tenants remain responsible for staff lists, customer outreach, and lawful bases for processing where they decide why and how data is used on the ground.

Contact for privacy requests: see Section 14.

2. Multi-tenant isolation & business context

The privacy architecture of AM | PM centres on siloed separation of business data.

  • Clerk Organizations: We use Clerk Organizations to define boundaries between venues or groups. Each tenant is associated with an organization identifier; in our datastore this typically maps to a businessId (or equivalent) that acts as a mandatory filter on scoped operations.
  • Appwrite & collections: Application data stored in Appwrite (including orders, menu items, expenses, print jobs, and related records) is structured so that queries are scoped by businessId. That structural guardrail helps ensure one venue's revenue, stock, and guest records are not returned to another tenant by normal application paths.
  • Limits of software controls: Isolation also depends on Tenants assigning correct Clerk roles, revoking access when people leave, and securing shared tablets and terminals physically. We cannot prevent misuse of legitimate credentials.

3. Categories of personal data we may process

Depending on how you interact with us, we may process:

  • Identity & account data: Name, email, phone, Clerk user identifiers, organization membership, role labels, and authentication factors (for example passkeys) where used.
  • Guest & reservation data: Names and contact details Tenants collect for seating, confirmations, service recovery, or loyalty, as configured by the venue.
  • Venue operations records: Reservation status notes, service incident notes, and lost-and-found logs where maintained by venue teams as part of business operations.
  • Transaction & operations data: Orders, line items, settlements, void reasons, staff attribution, timestamps, identifiers that tie actions to an authenticated user, and configuration metadata needed to run the service.
  • Payment-related metadata: References from payment partners, M-Pesa or STK-related identifiers used to match payments to orders, and gateway transaction references. We do not store full payment card numbers as a primary card vault.
  • Technical & security data: IP address, device/browser type, approximate location derived from network signals, cookies and similar technologies, diagnostic logs, error reports, and performance telemetry.
  • Communications: Messages you send us (support, privacy requests) and, where you opt in, marketing preferences.

We do not knowingly create unrelated behavioural profiles of guests across unrelated venues, and we do not sell personal data.

Where venue teams decide why and how operational records are used (for example service incident or lost-property follow-up), they remain primarily responsible for that processing context.

4. What we collect & why (purposes & lawful bases)

We collect data needed to run restaurant operations, enforce accountability, and meet basic transaction integrity — not unrelated profiling.

Staff identities & audit ("Recorded Identity"): Operational actions (creating orders, processing settlements, performing restricted voids, publishing menu changes) are associated with the authenticated user — for example via Passkey sign-in and/or Clerk user identifiers. This supports shift accountability, and fraud-resistant audit trails.

Purposes and lawful bases: Performance of our contract with Tenants and users with accounts; legitimate interests in securing the platform and preventing abuse; legal obligations where applicable; and consent where processing relies on consent.

Guest & customer details: For reservations, guest registration, or service recovery, Tenants may store names and contact information you provide. Purposes include seating, confirmations, and legitimate venue communication.

Lawful basis: Primarily performance of a contract or steps at your request; where Tenants conduct direct marketing, they should rely on consent or another valid basis and explain this at collection.

Payment-related metadata:

  • M-Pesa: We may process identifiers such as a phone number used to initiate or confirm STK push flows and to match payments to orders. We do not use this for unrelated marketing unless the venue has a separate lawful basis and you are informed.
  • Paystack & card flows: We capture gateway references and related metadata so settlement is idempotent (no double counting) and reconcilable. Full card numbers are handled by PCI-DSS-compliant providers, not stored by us as a primary card vault.

Technical, analytics & security data: We use hosting and analytics tools (including Vercel Analytics) to understand aggregate traffic and performance. We use error monitoring (including Sentry) to diagnose crashes and reliability issues. Depending on configuration, this may include session replay or console logs that could inadvertently capture typed content if staff paste sensitive data into the browser.

We configure these tools to reduce risk and sampling where possible, and use data only to secure and improve the service. Tenants should avoid entering secrets in browser consoles and client-side fields not intended for sensitive information.

Cookies & similar technologies: We use cookies and similar technologies required for authentication, security, and basic site function, and where applicable for analytics. You can control some cookies through your browser settings; core service cookies may be necessary for sign-in and fraud prevention.

5. Transactional integrity & audit trails

We maintain structured records so operations remain explainable to Tenants and regulators where applicable — a digital counterpart to disciplined books.

  • Menu versioning: When menu changes are published, the system may snapshot item state and associate the change with the administrator who authorized the publish (via Clerk user identity), supporting accountability for pricing and tax display.
  • Void auditing: Order voids that require elevated privileges (for example actions restricted to org:admin-level roles) are recorded with a void reason, timestamp, and identity of the actor.
  • Print jobs: Kitchen dockets and receipts routed through PrintBridge (or equivalent) may be logged in collections such as PRINT_JOBS so physical output corresponds to a persisted record — reducing the chance of unrecorded "phantom" orders.

6. Automated decisions

We do not use solely automated processing that produces legal or similarly significant effects about you. Audit and fraud-prevention signals may flag activity for human review where configured.

7. Kenya fiscal & regulatory context

AM | PM is used in environments subject to Kenyan tax and invoicing rules. The platform may aggregate or display figures using a standard 16% VAT configuration where applicable; whether a supply is taxable, zero-rated, or exempt is a legal determination for the Tenant.

eTIMS / KRA: We may retain data that supports future or partial eTIMS integration. Real-time OSCU submission is not guaranteed across all deployments; Tenants should treat the system as a digital ledger and complete filing through approved KRA processes until any integration is fully production-ready for their environment.

8. Retention, cleanup & performance

We balance legal and operational needs with system health and cost control. Large read volumes can stress databases; we design queries and caching so sessions only touch what they need.

  • Automated housekeeping: Scheduled tasks — for example a daily process around 7:30 AM East Africa Time (Nairobi) — may archive, cancel, or clean up stale unpaid orders and similar transient records from prior shifts, according to rules we configure with operational safety in mind.
  • Edge caching & narrow queries: Public marketing content and static documents (including this policy) are delivered without hammering your operational database. Application queries use business scoping to limit exposure and load.
  • No immortal storage promise: Exact retention periods vary by record type, legal requirements, and Tenant agreements; contact us or your venue for specifics about export before contract end where required.

9. Security & incidents

We apply administrative, technical, and organizational measures appropriate to the risk: encryption in transit where standard, access controls, tenant separation in software, monitoring, and testing — including automated checks on critical paths. No system is perfectly secure; Tenants and users must play their part as described above.

If we become aware of a personal data breach affecting data we control, we will take reasonable steps to mitigate harm and notify affected parties or regulators where required by law.

10. Processors, subprocessors & transfers

We use reputable infrastructure and service providers — including identity, database, hosting, email, and payment partners — who process data under agreements that require appropriate safeguards.

Where data is transferred outside Kenya, we rely on lawful mechanisms under the Data Protection Act (such as adequacy decisions, appropriate safeguards, or explicit consent where required) and vendor terms compatible with our obligations.

11. Your rights under Kenyan law

Subject to verification and exceptions in the Data Protection Act, 2019, you may have the right to:

  • Access personal data we hold about you;
  • Request correction of inaccurate data;
  • Object to certain processing, or request erasure where applicable;
  • Withdraw consent where processing is based on consent, without affecting prior lawful processing;
  • Lodge a complaint with the Office of the Data Protection Commissioner (ODPC) in Kenya if you believe your rights are infringed.

For data processed on behalf of a venue, we may need to coordinate with the Tenant — please also contact the establishment directly for booking or loyalty queries.

12. Children

The Service is intended for adult staff and patrons in a hospitality context. We do not knowingly pursue behavioural profiling of children. If you believe we have collected a child's data inappropriately, contact us and we will address it promptly.

13. Changes to this policy

We may update this Privacy Policy. We will revise the effective date and, where appropriate, provide notice through the Service or website. Material changes will be brought to your attention when the law or our risk assessment requires it.

14. Contact

For privacy requests, questions about this policy, or data subject enquiries:

See also our Terms of Service.

Appendix — Subprocessors & integrations

A non-exhaustive list of categories of subprocessor and typical processing follows:

  • Identity & access: Clerk Technologies, Inc. — authentication, organizations, sessions.
  • Application data: Appwrite Ltd / Appwrite Cloud — database, files, realtime.
  • Hosting & edge: Vercel Inc. — hosting, CDN, serverless, analytics.
  • Error monitoring: Functional Software, Inc. (Sentry) — crash reports, logs, optional session replay.
  • Payments: Paystack and/or other gateways, Safaricom (M-Pesa) — payment initiation, callbacks, telco flows.
  • Email / communications: Transactional email and service alerts via configured providers.

This list may change as our stack evolves. Tenants may also introduce their own processors in their downstream operations.