> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Proactive outreach

> The agent notices a problem in your systems and reaches out before the customer files a ticket.

A payment failed. A shipment stalled in a carrier's network. A subscription is about to renew on an expired card. A booking was double-allocated.

In every one of those, the customer finds out on their own schedule — usually later, usually annoyed, usually after the problem got worse. Reactive support closes the ticket that follows. Proactive support means there is no ticket.

<Info>
  **This is only possible because the agent already watches your systems.** Support tools see
  conversations. Tied sees the order, the subscription, the shipment and the account, continuously —
  so there is something to notice before anyone writes in.
</Info>

## How a proactive conversation starts

<Steps>
  <Step title="A watcher fires" icon="radar">
    Provider state changes in a way you told Tied to care about — a payment failure, a tracking
    event that stopped moving, a renewal about to fail, a threshold crossed.
  </Step>

  <Step title="The agent works out whether reaching out is appropriate" icon="scale">
    Is this customer already in a conversation about it? Did we contact them yesterday about
    something else? Is the problem actually theirs to act on, or will it clear itself?
  </Step>

  <Step title="It checks consent" icon="shield-check">
    Recorded, attributable opt-in for outbound contact on this channel. No consent, no message.
  </Step>

  <Step title="It reaches out, with the fix ready" icon="send">
    Not "we noticed a problem, please contact us" — the problem named, what it means, and the action
    that resolves it, ready to take in the thread.
  </Step>
</Steps>

## Four trigger sources

| Trigger | Fires on |
| - | - |
| **Sync watcher** | A change in continuously-synced provider state |
| **Schedule** | A time you chose — a renewal date, a check-in cadence |
| **Score threshold** | A computed value crossing a line you set |
| **Webhook** | A provider event pushed to Tied directly |

A conversation counts as proactive when the trigger came from one of those **and** the first message in it went outbound. That combination is what separates genuine prevention from a fast reply, and it is checked rather than asserted.

## Consent is the real constraint

It is tempting to treat platform approval as the blocker on proactive messaging. It is not.

<Warning>
  **Messaging a customer who did not contact you first requires a defensible opt-in path** —
  recorded, attributable to a person and a moment, and auditable afterwards. That is a legal
  requirement in most of the places you operate and a channel requirement in several. Tied will not
  send proactive messages to a contact with no recorded consent for that channel, and the record is
  what you produce if anyone ever asks.
</Warning>

Get the consent path right and everything else is engineering. Get it wrong and the best-built proactive system in the category is unusable.

## Prove it on web chat first

Web chat has no platform gatekeeper, so the entire proactive loop — watcher, appropriateness reasoning, consent check, outreach, resolution — can be proven end to end without waiting on anyone.

That is the right sequence:

1. **Build and wire the watchers** for your account.
2. **Prove the loop** in the sandbox and on a live web-chat inbox.
3. **Promote to Apple Messages for Business or RCS** once brand onboarding completes.

Platform onboarding is calendar time you wait through, not work you do — so start it in parallel with the engineering rather than after it. See [Registration](/channels/apple-messages/registration).

## Who gets it

| Capability | Availability |
| - | - |
| **Syncs for context** — the agent knowing the customer's live order or subscription state when they write in | **Every plan.** A cheaper plan does not mean a blinder agent. |
| **Proactive outbound** — the agent starting the conversation | **Separately entitled**, because outbound carries reputational and consent risk that inbound does not. |

## What it costs

A proactive resolution is classified and priced like any other, by its [class](/pricing/resolution-pricing). It still only bills on a [positive signal](/pricing/resolutions), still voids on a reopen inside 30 days, and still voids retroactively on negative feedback.

## Next

<CardGroup cols={2}>
  <Card title="Actions and tools" icon="zap" href="/agents/actions">
    The connected systems the watchers watch.
  </Card>

  <Card title="Campaigns" icon="megaphone" href="/campaigns">
    Scheduled outbound to a defined audience — a different tool for a different job.
  </Card>

  <Card title="Resolution pricing" icon="tags" href="/pricing/resolution-pricing">
    How a resolution is classified and priced.
  </Card>

  <Card title="Registration" icon="badge-check" href="/channels/apple-messages/registration">
    The four-to-six-week queue to start now.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.