Give one customer special treatment
Set the rules against the person rather than the channel. Autonomy and memory both resolve at four scopes with the narrowest winning, and a contact is the narrowest, so a rule on one account overrides everything above it. Three settings do the work: hold their replies for a person, record how they are to be handled, and give their conversations the priority the engine reads.
Why the contact scope is the whole mechanism#
Both of the systems that decide behaviour — what Connect may do, and what Connect knows — use the same hierarchy: workspace, then channel, then endpoint, then contact, with the narrowest applicable rule winning. That single design fact is what makes special treatment cheap. You are not building an exception mechanism; you are using the one that is already underneath every decision.
The alternative people reach for first — turning the whole channel down to hold every reply — costs the business every other conversation to protect one. It also tends to be permanent, because nobody wants to be the person who turned it back up.
The three settings, in order#
Open the person and confirm you have the human rather than one of their addresses. One person can hold several identities across email, phone and messaging.
Result Everything you set now applies wherever they turn up, not only on the channel you happened to be looking at.
Set autonomy against that contact.
ask_before_sendis usually the right mode: every outbound to them waits for a human yes, while the rest of the workspace carries on unchanged.Result Replies to this account appear in the queue instead of going out.
Record how they are to be handled as a memory row at the contact tier — what matters to them, what to avoid, who owns the relationship, anything a new colleague would need on day one.
Result It applies to every future conversation with them, and it is readable: the memory viewer shows every tier for a person, including the tiers that are empty.
Raise the priority on their conversations.
Result This is not cosmetic. Priority is read by the engine when it picks work, so it changes what gets attention rather than only how a list is sorted.
Wait for their next message and check the queue.
Result The held reply is there, and reading it should show the memory having had an effect on how it is written. Both together are the verification; either alone proves half of it.
What else can be set per person#
| Control | Effect | Notes |
|---|---|---|
| Autonomy mode | Whether anything is sent without a person | Overrides the mailbox's, the channel's and the workspace's |
| Memory at the contact tier | How they are handled, durably | Applies to future conversations, not just the current one |
| Conversation priority | What the engine picks up first | A correction here changes behaviour |
| A voice profile on the contact | How the phone sounds to them | Beats a profile set on the line or by purpose |
| Follow-ups with reasons | Nothing is forgotten between contacts | A commitment without a reason is not useful to whoever inherits it |
| A block | Nothing at all, on every tagged channel | The other end of the same mechanism |
Keeping it from decaying#
Careful handling has a cost that arrives later: every held reply is a reply nobody has sent yet. A held draft has not been handed to any provider, so from the customer's side it is not a slow reply, it is silence — and the clock they are counting is still running. An account given ask_before_send and then not staffed is being treated worse than an ordinary one, not better.
- The rules stopped applying
- Something narrower was added, or the contact was merged and the surviving record is not the one carrying them. A merge preserves identities, stages, follow-ups, deals, cases and onboarding from both sides — check the survivor.
- Replies are held but nobody notices
- Nothing here queues itself to a named person. Pair the mode with a follow-up on the
taskchannel, which no drain ever sends and which therefore has to be closed by somebody. - The handling note is being ignored
- Check the tier. A note written at the workspace tier does not beat an older contradiction at the contact tier — the narrower one wins, correctly.
- Nobody remembers why this account is special
- Write the reason into the memory row rather than leaving the settings to imply it, and let the decision log carry the rest: it records what was decided, under which rule, and what happened.
Questions#
Can I do the opposite — let one trusted contact be answered fully automatically while everything else is held?
Yes. The resolution rule is about narrowness, not caution: a contact-scope autonomous setting wins over a cautious channel exactly as a contact-scope ask_before_send wins over an autonomous one. Be deliberate, because it is the direction with more downside.
Does this work on the phone as well as in mail?
Autonomy covers voice as a channel, and a voice profile can be set on the contact so the call itself sounds different for them. Both use the same narrowest-wins ordering.
How do I see everything Connect knows about this account?
The single-person view assembles their whole history across every channel, and the memory viewer shows what is stored at each tier. Between them they answer "what do we know" and "what have we told it", which are different questions.
Is there a limit on how many contacts can have their own rules?
None is documented. The practical limit is how many exceptions a team can remember and staff — twenty accounts on ask_before_send is twenty queues of silence if nobody works them.