Qiza Privacy Policy

Effective: September 10, 2026

This policy explains how Qiza LLC, which operates Qiza, handles information when a business uses the bot, its shift portals, and its TV dashboard. The business that invited the bot also controls its Discord server, channels, roles, employee access, and workplace policies.

Information we process

• Guest submissions: the name entered by the guest, location, employee position, requested shift date and configured shift time, and claim activity.
• Discord login: Discord user ID, username or global display name, and the server roles needed to verify access. The login requests only Discord’s basic identify permission; it does not request email or a list of servers.
• Discord operations: server, channel, role, message, location, and employee-position identifiers; business settings; shift posts; approvals; cancellations; support requests, suggestions, replies, reference numbers, and support logs.
• Business administration portal: current Discord administrator status or membership in the business’s explicitly approved portal role or individually approved Discord account is checked before displaying business configuration, location links, backup health, or business exports. Safe settings changes are attributed to the signed-in Discord account.
• Staff onboarding: the applicant’s Discord member ID, requested employee name, location and positions, account creation and server-join timestamps, manager approval or denial, and the resulting role and nickname changes.
• Approved-shift ledger: timestamp, location, shift date, original owner, person covering, and approving manager.
• Manager decisions: when a manager denies a coverage claim they must give a reason. That reason is recorded on the private manager ticket and sent to the person who claimed the shift. It is never posted to the open shifts channel that the whole location can read.
• Qiza Shift Coverage: during the native-app beta, Qiza stores the signed-in employee, workplace, shift date and label, optional position and note, claim, status, and approving or denying manager. Current membership and the business's Shift Coverage subscription are checked again on every page and every change.
• Qiza staff accounts: a business may register an employee so they can use Qiza without a Discord account. We store the name the manager entered, the workplaces and role they were given, and one or more sign-in credentials — a personal email address today, or another supported account if one is offered later. A business Administrator may send a 24-hour invitation and Qiza records whether it was sent, accepted, expired, or cancelled. Workplace access remains pending until the invited person returns a code delivered to that registered address. A credential is never stored in readable form. It is held as a keyed one-way hash used to find the account, plus an encrypted copy so a manager can confirm a masked version of what they typed. Sign-in codes are stored only as a keyed hash, expire after ten minutes, and are single-use. When a legacy phone account is moved to email, the old phone credential is retired and erased.
• Platform directory: a separate database records who each customer is, independently of any one product: business name, the short name used in its portal addresses, its Discord server identifier where it has one, its location codes and timezones, and which Qiza products it currently has access to. It holds no employee or guest information.
• Coverage text number: a business may save one contact number per location — typically an internal dispatch or scheduling line, not a personal number. It is stored with that location's settings and is used only to pre-fill a message in the employee's own messaging app. See “Text messages” below.
• Security data: source IP address held briefly in process memory to rate-limit abusive guest submissions, plus short-lived signed login/form tokens.
• Guest safety screening: text entered in public guest name fields is checked locally against built-in and business-configured language rules before posting. Rejected text and the matched rule are not included in the safety event log.
• Guest account matching: an accepted guest request name may be compared with display names of location-authorized members in that business’s Discord server. A single exact match may be referenced on the shift as an unverified Discord account; it does not authenticate the submitter or grant guest access to that account.

How we use information

We use this information only to operate shift coverage, verify identity and access, route requests to the correct business and managers, send configured notifications and calendar files, prevent abuse, let managers verify staff access, troubleshoot failures, maintain approval records, and connect a business subscription to the correct account.

Text messages and sign-in codes

Qiza LLC sends only transactional access emails. When a business Administrator invites an employee, or a registered employee requests access, Amazon SES (or Postmark if the rollback provider is selected) receives the destination email address and the invitation or short sign-in message needed to deliver access. These requested transactional sign-in emails contain single-use six-digit codes that are requested by the recipient; Administrators cannot view or hand them out. Qiza does not use the address for advertising and does not send an SMS sign-in code.

The same-day coverage handoff sends nothing either. When a business has saved a coverage text number and a shift is happening today, the bot offers a link that opens the employee's own messaging app with a message already written. The employee chooses whether to send it, and it is sent from their own phone and phone number by their own mobile carrier. We are not the sender, no message passes through our systems, and that feature collects no phone number at all.

Legacy phone sign-in credentials are removed when management assigns the employee an email address. See “Qiza staff accounts” above.

Billing information

Business administrators may open Paddle's secure checkout from the authenticated administration portal. Paddle collects and processes contact, billing, tax, and payment-card information under its own privacy terms. Qiza does not receive or store complete card numbers. We retain only an opaque business reference, Paddle customer and subscription identifiers, the approved plan identifier, subscription status, and recent signed-event identifiers needed to prevent duplicate processing and control service access.

Sharing and service providers

Legacy bot shift details are delivered to the business’s Discord server. Native Qiza Shift Coverage beta records remain in Qiza's business database and are not copied into Discord during the side-by-side test. When the business enables Slack notifications, relevant names and shift details are sent to its configured Slack workspace. Discord, Cloudflare, Amazon SES, Postmark when configured as the rollback provider, the hosting provider, the QR-image provider, and Paddle process limited data needed to deliver the service. QR images encode portal or invite URLs, not employee shift records. Paddle acts as the payment provider and merchant of record for purchases made through its checkout. We do not sell personal information or use it for advertising.

Portal visibility: guest portals and TV boards do not require a Discord login. The claim page and TV board may show abbreviated shift-owner and coverage names, dates, and status to anyone who has the business-and-location link. Businesses should distribute and display those links only in appropriate workplace contexts.

Operator access: Qiza LLC maintains an internal console used to set up and support customers. It shows business names, portal addresses, location codes and product access across all customers, and can create new customer records. It does not display guest submissions, shift history, or any stored secret. For account support it shows employee names, roles, and only a masked sign-in email or the final four digits of a legacy phone credential. Access requires administrator permission in Qiza LLC's own Discord server, is rechecked on every request, and its sessions are shorter than a business portal session.

Cookies and OAuth tokens

We do not use advertising or analytics cookies. Discord login uses one secure, HTTP-only, same-site nonce cookie that expires after approximately ten minutes. The business administration portal also uses a signed, HTTP-only, same-site session cookie lasting up to eight hours; current Discord administrator, approved-role, or approved-account access is rechecked on every request. The Qiza LLC operator console uses its own separate session cookie, limited to that console's address and to two hours. A Qiza staff account signed in without Discord uses its own signed, HTTP-only, same-site cookie lasting up to thirty days; the account's current workplaces, role, and credential version are re-read from our records on every request, so access ends immediately when a business removes someone or changes their email, whatever the age of the cookie. Discord access tokens are used in process to retrieve the authorized account’s basic profile and are not written to the bot’s files or database.

Retention

• Rate-limit IP entries expire from memory after approximately ten minutes and are also cleared whenever the bot restarts.
• OAuth state expires after ten minutes; authenticated form tokens expire after one hour and are single-use.
• Shift-board messages and completed manager shift-decision tickets are automatically cleaned after the relevant shift-day rules. Staff-onboarding, cancellation-audit, and Discord debug/support records may remain until an administrator deletes them.
• Qiza staff accounts: when someone stops working for every business they were registered with, their sign-in credentials are erased — the email address, the hash used to find it, and the encrypted copy. They can no longer sign in and we no longer hold a way to contact them. Their name and the record of what they did are kept, because a shift approval or a coverage record that has lost the name of the person involved is of no use to the business it belongs to. A credential is erased only when the last workplace ends: someone who stops covering one location but still works at another keeps their account. Sign-in codes are deleted once used or expired.
• Business configuration, the platform directory record, and approved-shift CSV ledgers remain until the business or operator deletes them. Encrypted recovery copies are limited to the newest 30 snapshots per business and are removed with that business's stored data.
• Minimal subscription identifiers, status history, and signed-event identifiers remain while needed for billing, access control, accounting, dispute handling, and legal obligations.

Choices and deletion requests

Discord login is optional because guest mode is available. A user or business may ask to access, correct, or delete information where applicable. Some records may be retained when reasonably necessary for security, dispute resolution, or legal obligations. Email [email protected]. Please identify your business and Discord server when making a request.

Security and changes

We use HTTPS, restricted OAuth scopes, signed expiring forms, access checks, encrypted storage for business-specific Slack webhook secrets, recovery snapshots and staff sign-in credentials, keyed one-way hashing so a credential cannot be read back from our records, single-use expiring sign-in codes stored only as hashes, input validation, local guest-language screening, rate limits, and tenant-separated configuration. No system can guarantee absolute security. Material policy changes will be reflected by updating this page and its effective date.

Operator

Qiza is operated by Qiza LLC.