Privacy and data handling policy

Data we collect

• Lead intake: name, phone, email, requested needs, geography, and optional context.
• Provider onboarding intake: business name, contact, listing context, and proof notes.
• Subscriber capture: email and source metadata.
• Optional analytics metadata: request identifiers, context tags, and consent flags used for operations and moderation auditability. No phone/email payloads are stored in analytics event bodies.

How we use data

• Route forms into queueed operations, moderation, and safe follow-up workflows.
• Power anti-fraud and safety checks (timing, duplicates, suspicious payloads, suspicious sender patterns).
• Enable right-to-access and right-to-delete support workflows under authenticated controls.
• Improve matching quality and route reliability through non-PII telemetry.

Legal basis, consent, and communication preference

• Consent is collected at intake with version (`consent_version`) and timestamp (`consent_timestamp`) and stored for traceability.
• Marketing communications are optional and default to opt-out unless explicitly checked.
• Users can withdraw marketing consent in follow-up communications or by request.
• We do not use dark patterns, third-party phone verification, or forced checkboxes.

Retention

• Form records: retained for operational need and legal obligations, currently set to 18–24 months unless legal process requires shorter or longer retention.
• Provider records: retained while active in queue and for auditability as defined by operational policy.
• Event analytics: event identifiers are retained with pseudonymization controls for operational monitoring.
• Subscriber entries are retained by operational use and consent state, with deletion/redaction path available on request.

Service providers and third parties

• Cloud-hosted infrastructure for delivery, queueing, and data durability.
• Analytics endpoints and email transport for operational notifications.
• Monitoring systems used for reliability and error observability.
• Any processor changes are documented in deployment and release notes when activated.

Data rights

Data rights requests are supported through authenticated DSAR and erase flows. For identity verification support, include your request context, matching IDs, and contact method details when reaching out for manual handling.

• DSAR / export: identity-scoped payload for all applicable records.
• Erase / redaction: lawful delete queue with audit log for completion verification.
• Data quality and correction requests: routed to the same moderation queue for resolution.

Trust pages and disclosures

Read: Trust framework, Provider policy, Complaint process.