Last updated: 2026-05-14 Effective date: TBD (set at production launch)
This document is the privacy policy for the Missed Lead / Follow-up Gap Audit utility ("the Service"). It is read together with the Terms of Service. Defined terms in this document carry the same meaning in the Terms.
The Service is a read-only diagnostic audit utility for agencies that manage multiple client accounts inside a third-party CRM platform ("the platform"). An agency installs the Service via OAuth from the platform's marketplace and authorizes a fixed scope list that is read-only for CRM business data, plus a narrow oauth.write OAuth control-plane carve-out used only to mint per-location tokens (see §4 and the Scope Justification).
The Service does not write back to the platform, does not send messages on behalf of the agency or its client accounts, and does not generate any financial estimates from its findings. Its sole output is a set of metadata-only diagnostic indicators that the agency reviews internally.
This policy describes what data the Service collects, how it is used, how it is protected, and the rights an installing agency has over it.
designated by that agency as operators of the install.
the connected platform. The Service does not establish a direct relationship with those client-account end users; their data is reflected only through aggregate, hashed, metadata-only fields.
The following categories are stored in the Service's databases:
| Category | Examples | Persisted form |
|---|---|---|
| Agency identifier | Hash of the platform's company identifier (SHA-256) and, optionally, an AES-256-GCM ciphertext of that identifier | Hashed; optional encrypted ciphertext at rest |
| OAuth tokens | Access token, refresh token from the platform | Encrypted at rest (AES-256-GCM, bound to the installation) |
| Granted scopes | The scopes the agency authorized: 6 read-only CRM-data scopes plus 2 OAuth control-plane scopes (oauth.readonly, oauth.write); the latter mint per-location tokens and are never used to write CRM business data | Stored as a list of scope strings |
| Scan metadata | Per-scan timestamps, per-detector version pins, location id hashes, error / partial outcome counts | Per-scan record (metadata only) |
| Findings (metadata only) | Detector type enum, severity enum, confidence float, entity-id hash, reason-code strings, neutral evidence aggregates (timestamps, counts, threshold breached) | Per-finding record; metadata-only evidence |
| Feedback | Agency's own rating per finding: true_positive, false_positive, or ignore; optional free-text comment up to 500 characters the agency typed itself | Per-finding feedback record |
| Beta / usage metrics | Lifecycle events (install funnel, scan funnel, feedback distribution, payment events) with a numeric value, an event-type tag, and a PII-free metadata blob | Aggregate usage record (PII-free) |
| Billing state | Payment status, payment-link sent / paid timestamps, opaque external payment reference (≤ 64 chars), internal notes (≤ 500 chars, never returned to the agency) | Billing record (no card data) |
The following are not consumed into application memory beyond the specific aggregates listed in §3, and are not persisted at rest:
conversations inside the connected platform.
documented metadata fields before any persistence call is reached).
instrument data. Payment processing is handled entirely on the payment provider's side (see §7); we only receive an opaque session reference and a manually-toggled status enum.
beyond the OAuth-issued workspace identifier.
The above is enforced at the schema layer (column-name allowlist guard), at the persistence boundary (recursive PII-key rejection on every evidence_metadata write), at the AI surface (pre-check redaction of email- and phone-shaped patterns), and at the OAuth scope layer (no recording / transcription scope is requested or accepted).
returned by the platform and emit findings that are stored in the metadata-only shape described in §3. The agency reviews these findings inside the Service's dashboard.
distributions are passed to a third-party AI provider (see §7) to produce a short markdown draft summary for the agency's own review. The AI draft is never sent to the agency's client accounts and is never used to generate automatic messages. See the Scope Justification §7 for the AI policy contract.
(counts of installs, scans, feedback distributions, payment events) are used to refine detector thresholds and improve the product.
audit metadata to assist troubleshooting. Support staff do not access the connected platform on the agency's behalf.
payment provider's checkout session against the agency record using the opaque external reference. We do not pull the agency's billing history out of the payment provider.
The Service does not sell agency data. The Service does not share data with third parties except:
in §7).
in a relevant jurisdiction). When permitted by law, we will notify the affected agency before complying.
successor entity inherits the obligations of this policy.
| Processor | Purpose | Data shared | Where data is held |
|---|---|---|---|
| Anthropic | AI draft summary generation | Aggregate counts, severity distributions, masked identifiers, neutral metadata. A pre-check pass redacts email- and phone-shaped strings before transmission. | Anthropic processing region |
| Stripe | Payment processing (Stripe Payment Link) | Agency identifier is passed as client_reference_id on the checkout URL. We do not see card data; the payment provider holds the payment instrument record. | Stripe processing region |
| Resend | Transactional email delivery | Aggregate, agency-addressed notifications only. No client-account end-user PII is sent. | Resend processing region |
| Hetzner Cloud | Service hosting (compute, database, object storage) | All of §3 at rest, on the Hetzner-managed infrastructure region selected for production. | EU region (Hetzner) |
| Cloudflare | DNS resolution for the Service's public domains | Public DNS records only. The Service's OAuth webhook subdomain is configured DNS-only (proxy off) so request body bytes used for signature verification are preserved. | Cloudflare's anycast DNS infrastructure |
Each processor is bound by its own data-processing agreement and is listed here so that the installing agency can review the list before authorizing the install. The list is updated when subprocessors change.
data ("AAD") bound to the installation id and field name so that a row swap or field swap fails decryption rather than silently surfacing the wrong token.
Lax, Secure in production). OAuth tokens themselves are never placed in the cookie.
one-shot state token consumed on the OAuth callback.
eight (6 read-only CRM-data scopes + 2 OAuth control-plane scopes, oauth.readonly and oauth.write; see §2–§3 of the Scope Justification). oauth.write is a narrow control-plane carve-out used only to mint per-location tokens via POST /oauth/locationToken; no CRM-data write or recording scope is requested, and no CRM business object is ever created, updated, or deleted.
internal HTTP service to the loopback interface and terminates TLS at a separately-managed reverse proxy.
redacted by a defence-in-depth wrapper. Token values, state values, and authorization codes are not logged.
test suite; the evidence_metadata write path rejects forbidden keys (body, message, name, email, phone, firstname, lastname, fullname, raw_*).
Security is implemented as reasonable industry practice. We do not claim any specific certification (SOC 2, ISO 27001, or similar) at this time. This statement is updated as the security posture matures.
the install is active. The Service does not automatically delete scan history or findings, so the agency can review long-running trends.
record is marked uninstalled and kept as an audit log entry. The OAuth tokens stay encrypted at rest but are no longer used to call the platform.
encryption key associated with its records be rotated, rendering the stored ciphertexts unreadable to subsequent operators. This is a manual operation handled by the staff operator.
retention with automatic purge of scan history and findings beyond that window. This policy is activated after agency-base growth makes manual purge impractical and is announced before activation.
install via the support channel listed in §13.
the Service's dashboard.
to the platform; correction of source data happens on the platform itself. For data the Service has originated (feedback, comments), the agency edits or removes it directly from the dashboard.
Disconnect option in the Service. Follow up with a deletion request to the support channel for key rotation if a stronger assurance is required.
the support channel; we exclude your install from aggregate-only analyses on a best-effort basis.
The Service operates from the EU region (Hetzner Cloud Germany). Some subprocessors (Anthropic, Stripe, Resend) may process data outside the EU under their own data-processing agreements. When required, transfers are made under Standard Contractual Clauses or equivalent legal mechanisms.
The Service is intended for use by businesses (agencies) and is not directed at minors. The Service does not knowingly collect data about individuals under 16.
The Service is operated by Doptar (entity formation pending: Wyoming LLC, planned at the operator's MRR threshold; until then, operated as a sole-trader posture from the EU).
Material changes are announced via an in-product banner and a notification to the agency-owner email on file at least 30 days before the change takes effect. The changelog at the bottom of this document records each revision. Continued use of the Service after a notice period is treated as acceptance of the revised policy.
| Date | Change |
|---|---|
| 2026-05-14 | Initial draft. |