Use the least data needed to make the path work.

Inquiry event

Source identifier, timestamp, customer-supplied contact details, service-request text, and workflow status needed to acknowledge and route the inquiry.

Operational routing

Agreed staff destination, provider identifiers, delivery status, follow-up timing, suppression status, and acceptance-test evidence.

Commercial records

Buyer contact, written scope, selected plan, payment-path identifier, invoice or receipt status, and support history.

Website measurement

Session identifier, buyer reference when present, page path, dwell time, scroll depth, selected source and route, plan view, checkout click, referrer, UTM values, device viewport, language, timezone, and a hashed network identifier.

Least privilege

• Request only the access required for the accepted path.
• Prefer provider-native tokens, scoped credentials, or dedicated destinations where supported.
• Do not request broad CRM or administrator access when a narrower route is sufficient.

Purpose limitation

• Use customer inquiry data only to operate, test, support, and document the accepted service.
• Do not sell customer or prospect data.
• Any AI processing or additional processor must be identified in the written scope when applicable.

Excluded by default

• Protected health information, payment-card data, government identifiers, passwords in email, and regulated or highly sensitive data.
• Open-ended access to unrelated systems.
• Unsupported sources or destinations not named in writing.

Retention and handoff

• Retention follows the accepted service, support, legal, and evidence needs.
• At cancellation, credentials and active routes are removed or handed back as the written scope requires.
• Deletion requests can be sent to the company inbox and are evaluated against operational and legal obligations.