Zoril SMS Privacy Policy

1. Operator and scope

Zoril SMS is a service under Zoril Systems, managed by Gophine Services Uganda Company Limited. Our office is at Anzevu, Eruba, Vurra, Arua, Uganda. This policy covers sms.zoril.app, accounts and organisation workspaces, contact management, messaging and campaigns, automations, reporting, the SMS API, connected Android gateways, optional AI tools, payments and support.

For our own account administration, support, billing and security records, we determine how the data is used. For contacts and communications uploaded by an organisation, that organisation determines the purpose and lawful basis; we process the data to provide its messaging service. A recipient should normally contact the organisation that sent the message first. Features depend on the assigned plan and deployment; describing a feature here does not grant access to it.

2. Information processed

We process information you provide and records created when you use the service. Only supply data you are authorised to handle.

• Account and organisation information: name, email, membership, role, plan, subscription status and account activity.
• Contacts: names, phone numbers, normalised country/number, tags, groups, custom fields, source, consent evidence and suppression/opt-out records.
• Communications: message text, sender/recipient numbers, schedules, campaign membership, conversation history, delivery status, timestamps and gateway attempts.
• Gateway/integration records: persistent device identifiers, connectivity, SIM-related configuration, API-key hashes and usage, webhook settings and delivery attempts. Integration secrets must remain private.
• Billing: payment telephone number where supplied, amount, transaction reference/status, credit balance and ledger records. Yo! Uganda processes mobile-money payments; we do not require your mobile-money PIN.
• Support and security: contact-form submissions, correspondence, audit records, request/error logs and network-address information used to limit abuse.

3. Purposes and lawful basis

We use data to authenticate users, maintain tenant separation, route and schedule messages, show delivery/conversation history, enforce plans and limits, process payments, resolve support requests and prevent abuse. Usage reporting is based on service records; delivery analytics are not proof that a recipient read an SMS or made a purchase.

Account/service processing supports the service relationship. Security and fraud prevention protect customers and the platform. Legal obligations may require certain records to be retained or disclosed. Organisations are responsible for the appropriate legal basis for their own recipient data and communications. We do not sell customer contact lists or message content.

4. Contacts, imports and consent

Contact tools can normalise phone numbers, identify or merge duplicates, maintain groups and tags, save segments, and record import history and last communication dates. Personalisation uses names and custom fields supplied by the organisation. Segment rules can select recipients using those attributes and communication history; they do not establish that a person has consented or that an imported balance or purchase record is accurate.

Consent evidence and withdrawal history are recorded separately from contact details. Suppression records help prevent further unwanted messages, including when a contact is re-imported. Marketing campaigns use sender identification and opt-out safeguards; other sending tools and integrations still require the organisation to check their applicable consent and content duties.

Only import information obtained lawfully and necessary for the intended communication. Financial or other sensitive information must be restricted through the protected-field controls, not placed in unrestricted custom fields. Access restrictions on a field do not make it suitable to include in an SMS, export, webhook or AI request. Exports create a separate copy for which the downloading organisation is responsible.

5. Messaging and automation records

Individual and group messages, personalised previews, saved templates, recently sent recipient lists, scheduled and recurring campaigns, inbox conversations and automated replies can involve storing message text, phone numbers, recipient selections, merge-field values and timing information. Recently sent lists can make prior recipients available for reuse; every new send still needs an appropriate lawful basis.

Campaigns, journeys and workflows process configured triggers, keywords, conditions, contact attributes and communication events to select or send messages. Queue and recovery tools retain processing states, retries, gateway responses and error information for reconciliation. Cancellation stops eligible pending work; it does not erase a message already handed to a phone or carrier.

Replies forwarded by a paired gateway become organisation conversation records and can trigger configured automation or webhooks. Do not treat the inbox as a confidential channel or assume that a human has read or acted on a reply.

6. Android gateways and permissions

The Android gateway uses SMS and phone-related permissions to send and forward SMS, select supported SIMs and report send/delivery events. Camera access supports QR pairing when used. Background activity and network access support polling, connectivity reports and reconnection. Device identifiers, pairing credentials and SIM-related settings support routing and device management; an identifier can persist across ordinary reconnections.

Incoming SMS received by the connected gateway may be forwarded to the organisation, not just replies to a particular campaign. Use a dedicated gateway phone and SIM rather than a personal phone that receives private messages or verification codes. Inform anyone whose communications could be captured and obtain the permissions required for the device and its data.

Removing the gateway connection or revoking its credentials stops authorised future access but does not erase SMS already stored on the phone, recipient devices or other systems. Android settings, permissions, battery restrictions and carrier support can affect what is transmitted.

7. Team and platform access

Authorised organisation members can access records allowed by their role. Protected custom fields are restricted to organisation administrators; include only necessary information and review team access. Platform Super Admin message-monitoring pages show aggregate counts rather than message bodies or recipient numbers. This restriction is not a claim that message text never exists on the server or cannot be processed for delivery.

Platform administrators manage organisations, users, assigned plans, limits, credits, suspension/reactivation and operational/security records. Administrative changes can create audit records identifying the actor, action, organisation and time. Account support and administration do not make customer contact lists available for platform marketing.

8. Providers, API and AI tools

Hosting, authentication, email, payment and mobile-network providers process information needed for their services. Customer-configured API integrations and webhook destinations can receive message content, recipient numbers and events within their authorised scope. Webhook attempts and API activity are recorded for operations and security. Organisations must assess their recipients and providers, protect credentials and configure destinations carefully.

Optional AI-assisted tools use Google Gemini. Depending on the operation, submitted prompts, message text, conversation context or campaign results may be sent to Google to generate suggestions or analysis. Use only necessary information and do not submit secrets or sensitive personal data. AI output requires human review; do not assume it is accurate, private to the workspace alone, or a legal determination. Google's applicable service terms and data-handling arrangements also apply to that processing.

We may disclose records when required by law or to address fraud, abuse or a serious security incident. This policy does not certify that every customer-configured third party meets a particular compliance standard.

9. Billing, credits and referrals

Subscription records include assigned plans, trial and renewal dates, feature allowances, account restrictions and usage. Credit/top-up records can include amounts, payment phone numbers, transaction references, verification status, credit adjustments and balances. Promotional or referral records can associate an account or visit with a referral source or administrator-granted benefit.

Yo! Uganda processes supported mobile-money payments. We use payment status and references to verify purchases and resolve disputes; a pending request is not a completed payment. Do not provide a mobile-money PIN, password or one-time authorisation code to Zoril or its support team. Payment records can have legal or accounting retention needs distinct from messages.

10. Analytics and browser storage

The site uses browser storage for sign-in/session handling and preferences. Selected public pages store a random visitor identifier and referral code to measure visits and sources, with a session marker to avoid repeated visit events. Records can include page paths, referring websites and campaign sources. A random identifier is pseudonymous, not a guarantee of anonymity. Clearing browser storage removes local identifiers and may sign you out; it does not delete previously recorded data.

Delivery, campaign and usage analytics use message states, timestamps, replies and available click events. Some figures are estimates and others are not tracked. A delivery report or link click does not prove who read a message or establish a purchase, payment or appointment outcome.

Tracked message links can record click activity with a hashed network address and request metadata. A hash is a protective measure, not proof of anonymity. Organisations using tracked links must explain the tracking and provide any legally required consent or choice. Do not assume a universal tracking opt-out is automatically applied by the platform.

11. Security and SMS limitations

We use authenticated access, role checks, organisation isolation, hashed API keys, audit records and secure web connections to protect service data. Security and abuse monitoring may record failed access attempts, request metadata and network addresses. Hosting infrastructure provides encryption at rest where supported; protections depend on the deployed services and their configuration. Use device locks, protect secrets, revoke compromised keys and review team membership.

Ordinary SMS is not end-to-end encrypted. Message text is processed and stored where necessary for queues, delivery, history and automations, and is visible on recipient and gateway devices. HTTPS protects web/API transport; it does not encrypt the mobile-network SMS path end to end. No service can promise absolute security. Do not use SMS for secrets or highly sensitive personal data.

12. Retention and permanent deletion

Organisation administrators can configure contact and message retention in Deliverability → Compliance. Scheduled cleanup applies enabled settings when the cleanup job runs. There is no universal 30-day message deletion promise; retention depends on organisation settings, the deployed schedule and the purpose of each record. API/security logs, consent evidence, audit trails and payment records have separate handling and may be needed for legal obligations or disputes.

An authorised platform administrator can permanently delete an organisation and its associated service data, with an option to remove eligible user accounts. Accounts shared with another organisation, protected platform administrator accounts and the administrator's own account are not removed by that option. Platform security events and administrative audit records may remain. Organisation deletion is not a substitute for a separately required legal retention arrangement.

Deleting a contact or message is not necessarily removal of consent/suppression evidence or all linked service records. Closing a workspace does not erase independent copies in backups, exports, gateway or recipient phones, payment-provider records or third-party integrations. Stop schedules, export only records you may lawfully retain and revoke integrations before requesting closure. Permanent deletion may be unrecoverable; contact an authorised administrator or support about the scope of a request.

13. Rights and regulatory responsibilities

Subject to applicable law and verification, you may request access, correction, deletion, restriction or information about the use of your personal data, and withdraw consent where processing relies on it. Contact the sending organisation about its contact records; contact Zoril support about your account or our own records. We will explain any lawful reason that prevents immediate deletion. Withdrawing marketing consent does not automatically erase records needed to honour that withdrawal.

Organisations must keep consent evidence, honour opt-outs, limit collection, restrict sensitive data and follow Uganda's Data Protection and Privacy Act 2019 and applicable regulations, as well as destination-country messaging laws. School, financial and other industry templates do not authorise collection of children's or sensitive information or replace sector-specific requirements. This policy is not proof of regulatory registration or certification. You may raise a data-protection complaint with Uganda's Personal Data Protection Office or the relevant authority.

14. International processing and contact

Cloud services, Google Gemini, payment/network providers and customer integrations may process information outside Uganda. We and customer organisations must meet applicable transfer requirements for processing we respectively control. Organisations should assess their obligations and obtain any required safeguards or authorisations before uploading data or enabling integrations.

We may update this policy as service features or legal requirements change. The date above identifies this version. For questions, rights requests or security concerns, use https://zoril.app/#contact and identify the relevant organisation without sending passwords, API keys or unnecessary recipient information.