Where your leads live, and who can reach them.

When a lead leaves one of your sources and travels to SeeRM, it moves over an encrypted connection, the same kind of lock your bank uses. Nobody in between can read it.

The A grade above confirms the strict transport rules are in force: the connection is HTTPS-only, can't be downgraded, and is pinned for a full year.

The lead doesn't sit in the open once it arrives. It's stored on encrypted disks inside Amazon Web Services, the same infrastructure banks, hospitals, and government agencies run on.

SeeRM serves many dealerships from one platform, so the most important rule is that they never touch each other's data. That separation isn't a promise in a policy. It's enforced at the database itself, on every single read.

When your team signs in, the system checks who they are and returns only your dealership's rows. Ask for anyone else's and the answer is zero rows. Not by convention, by construction. We audited this directly on 1 July: an anonymous request returns nothing, and a signed-in dealer sees only their own store.

A lead's story teaches your floor for years. Their phone number shouldn't sit there that long. The rule we hold ourselves to: we keep no California identity we have no instructed business purpose to keep. For stores running chat alone, retention isn't a policy document, it's a standing job: contact identity that ages past thirty days is stripped automatically. The name, the email, the phone are removed; the anonymous story your numbers are built from stays.

For stores on the full SeeRM platform, your lead records are your system of record, held under your documented instruction for as long as we serve you and deleted within thirty days of the day we stop. The purge job knows the difference by construction: a store with a working lead deck sits outside its selection entirely, not outside its memory. Each run writes a log of every row it touched and every store it left alone, and we'll show you the log. And a customer's deletion request never waits for the calendar or the plan: asked, honored, logged.

This is the part most CRMs can't offer. The moment a consent record is created (the exact form a customer submitted, the disclosure they saw, the boxes they checked, the timestamp), we seal it with a cryptographic signature and link it to the record before it, like a chain.

If a single character were ever changed after the fact, the seal breaks and the check fails. You don't have to take our word for that: the verifier re-runs the math in your browser against our public key.

Some of your sources (Qualify Wizard especially) arrive carrying real financial detail: credit scores, charge-offs, repossessions. You asked, rightly, that Addie never repeat any of it back to a customer. Here is the posture for those sources.

The protection isn't an instruction we hope Addie follows. It's a filter at the door: the sensitive fields are stripped from the lead before Addie is ever given the message to work from. She can't repeat what she was never handed. Her reply routes the customer to the person who should have that conversation:

The same filter is an allowlist, not a blocklist: a field is invisible unless it's explicitly marked safe to pass, so a new field arriving in a feed next month lands on the safe side by default, not the exposed side. It's the identical pattern we already run on the rest of the platform's data intake.