# CON-162 — A chat conversation is not a marketing opt-in

> Consent inferred from a chat widget or an inbound conversation must not be used to justify a marketing use case.

- **Rule ID:** CON-162
- **Layer:** Consent flow (`CONSENT_FLOW`)
- **Checks:** `consent basis vs use case`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the submitted form
- **Fix type:** Supply evidence only you hold
- **Required by:** CTIA
- **Applies:** Applies when consent was collected by chat, and the use case is MARKETING, MIXED, SWEEPSTAKE and LOW_VOLUME.
- **Canonical URL:** https://ekas.io/rules/10dlc/consent-flow/con-162/

## Why this rule exists

Somebody who opened a support chat consented to that conversation, not to a promotional programme. The two get conflated because the chat platform holds a phone number and an apparent agreement to be contacted, so the marketing list builds itself out of support enquiries — which is exactly the mismatch between what was agreed and what arrives that drives complaints.

## How to fix it

Either register the programme as customer care, matching what the chat consent actually covers, or add a marketing opt-in inside the chat flow with the full disclosure and record it separately. Done when the use case and the consent describe the same thing.

## Example of a compliant value

```text
In-chat: "Want Acme Coffee offers by text too? Reply YES to opt in — msg frequency varies, msg & data rates may apply, reply STOP to unsubscribe." Only repliers join the marketing list.
```

## Common mistakes

- A conversational opt-in inside the chat is fine and is the fix; what fails is treating the existence of the conversation as the consent.