Privacy Policy

This policy covers two groups: staff — admins and counter operators at an organization using SmartQS — and visitors — the public who receive a token or check a queue status page. It applies to smartqs.app and its subdomains, and the Counter, Kiosk, and status-page apps.

For visitor and token data, the organization running the queue (the clinic, hospital, bank branch, government office, or other service provider you visited) is the data controller — they decide why that data is collected. SmartQS acts as their data processor, handling it only on their instructions and under a data processing agreement. For staff account data and this website itself, SmartQS is the controller.

From visitors: name and mobile number at the point a token is issued, used to identify a visitor on the status page and to deliver queue notifications. We don't require a visitor to create an account or install an app.

From staff: name, email, and role, used for authentication and access control within their organization's account.

Operational data: token and queue events (issued, called, served, skipped) tied to a department and counter, kept for reporting. Retention length is configurable per organization.

We don't collect payment details, health records, or government ID numbers through the queue flow itself, and we don't run advertising or tracking scripts on visitor-facing pages.

Where GDPR applies: issuing and serving a token is processed under contractual necessity (fulfilling the service a visitor asked for at the counter); account security and abuse prevention under legitimate interest; and any optional notification channel a visitor opts into (SMS, WhatsApp) under consent, which can be withdrawn at any time. Where India's DPDP Act applies, the same token-issuance data is processed on the basis of the visitor's explicit consent, given at the point a token is issued.

To run the queue: issuing tokens, showing live position on a kiosk display or status page, and sending Web Push, SMS, or WhatsApp notifications when it's a visitor's turn. To run the product: authenticating staff, enforcing role-based access, and generating the reports an organization has configured. We do not sell personal data, we do not use it for advertising, and we do not share it across organizations — every organization's data is tenant-isolated (see our Terms of Service for what that means at each deployment tier).

This marketing site sets no cookies, uses no browser local storage, and loads no third-party analytics, advertising, or font scripts — every asset on this site is served from smartqs.app itself. Because nothing is set, there's no cookie banner: there's nothing to consent to. The product apps (Counter, Kiosk, Admin Console) use browser storage to hold a staff session token, which is functionally necessary and not a tracking mechanism.

Every public status-page link uses an opaque, non-sequential identifier. Knowing one visitor's link doesn't let you guess another's, and the link alone doesn't reveal a visitor's name or mobile number without the identity check built into that page.

We rely on a small set of infrastructure providers to run the platform: cloud hosting and storage (AWS), and browser push services for delivering notifications. SMS and WhatsApp gateway providers will be added to this list if and when those channels ship. We'll publish a named sub-processor list before onboarding any production tenant, and notify organizations of material changes to it.

Data residency depends on an organization's deployment tier — pooled with row-level isolation, a dedicated database, or a fully separate account with a contractually pinned region (see the Deployment tiers section on our homepage). Where a transfer of personal data across borders is unavoidable (for example, a shared regional deployment), it's made subject to appropriate safeguards, such as standard contractual clauses, as required under GDPR.

Token and queue event retention is configurable per organization and defaults to the shortest period needed for reporting. When an organization's account is closed, their tenant data is deleted or irreversibly anonymized within a defined window set out in their order form, unless a longer period is required by law.

Data in transit is encrypted (TLS). Access to staff accounts is role-based, every persisted record is scoped to its tenant, and public identifiers are opaque rather than sequential — see our Terms of Service for what tenant isolation means at each deployment tier. We'll disclose a security incident affecting personal data to affected organizations without undue delay, and within the timelines GDPR and the DPDP Act require once we're processing production data.

Subject to the law that applies to you, you may have the right to: access the personal data we or an organization hold about you; correct inaccurate data; request erasure; restrict or object to processing; receive your data in a portable format; and withdraw consent at any time where processing is based on consent. If you're in the EU/UK, you also have the right to lodge a complaint with your local data protection supervisory authority. To exercise any of these, contact the organization that issued your token first — they control that data as the data controller — or write to us at contact@smartqs.app and we'll route it to them.

SmartQS isn't directed at children, and we don't knowingly collect data from children beyond what an adult submits on their behalf at a counter (for example, a parent generating a token for a child's appointment).

SmartQS doesn't make any decision that produces legal or similarly significant effects about a visitor using automated processing alone. Queue ordering follows a fixed, auditable set of rules operated by staff, not a profiling algorithm.

We may update this policy as the product develops before general availability. Material changes affecting an onboarded organization will be communicated directly, not just posted here.

Questions about this policy, or a data protection / DPDP grievance request: contact@smartqs.app. We aim to acknowledge grievance requests within the timelines the DPDP Act sets out once we're processing production data; a named grievance officer will be published here before then.