A message went to the wrong person

How a recipient is decided#

Three things decide it, and none of them is a free choice at send time. The identity maps one address on one channel to a Person. The thread decides who a reply goes to, because a reply belongs to the conversation it answers. The mailbox role decides which address it is sent from — which is why, on a held draft, the recipients and the body are editable and the sending mailbox is not.

Identity

One address on one channel, resolving to one Person. A shared address such as info@example.net is one identity however many people read it.

Person

The human. Several identities across email, phone and WhatsApp can resolve to the same one; that is what makes a single history possible.

Thread

The conversation. Replies stick to it, which is correct behaviour and is also why a mis-linked identity keeps producing the same wrong recipient.

phone_key

The normalised form of a number used to match a caller. A contact created without one cannot be found by the number it was created from.

Causes, most likely first#

1. Two people behind one address. A shared or role address resolves to a single Person. The reply is correct for the identity and wrong for the human who wrote, and nothing in the record looks unusual.
2. A merge that joined the wrong records. Merging two people joins their identities. If one identity belonged to somebody else, every future reply on that channel goes to the merged person.
3. A number with two rows. When a number resolves to two contacts, identify_caller takes the oldest — deterministic, and wrong when the older row is the stale one.
4. A contact created without phone_key. Historically most contacts created by lead capture on the host had none, so a later call from the same number created a second record instead of matching. Lead capture now sets it from the start.
5. A recipient edited on the draft. Recipients are editable before approval, and an edit is what gets sent — Connect does not write over it. An address corrected by hand on one draft does not correct the identity behind it.

What Connect completed#

The message was sent, with the provider's own evidence, to the address the identity resolved to. It is recorded on that Person's timeline and in their history, and the allowance was charged. Everything the system was asked to do, it did — which is exactly why the record looks clean while the outcome is wrong.

What Connect did not complete#

Nothing was recalled, no correction was sent, and the identity was not repaired. The message also now sits on the wrong Person's timeline, which matters more than it sounds: a later summary or next action reads that history, so an uncorrected mis-link keeps influencing decisions after the immediate embarrassment is over.

What you can do#

1. Open the Person the message went to and look at their identities.

   Result You can see immediately whether the address belongs there, or arrived through a merge.

2. Correct the identity rather than the message.

   Result Every future reply on that channel follows the identity. Editing one draft fixes one message and leaves the cause in place.

3. If the address is genuinely shared, treat it as shared.

   Result A role address that several people use is not one human, and expecting per-person history from it will keep producing this.

4. If the relationship needs protecting while you sort it out, block the channel for that contact.

   Result A block is a memory row tagged block:<channel> against the contact, so it holds across channels and across future conversations rather than being a flag somebody can clear by accident.

What an administrator can do#

• Review recent merges. Merging is reversible only in the sense that records can be re-separated by hand; the safest fix is to check the identities before merging rather than after.
• Look for two contacts sharing one number, and decide which is current rather than leaving the oldest to win by default.
• Narrow autonomy for that contact to ask before sending while the identity is being repaired, so nothing else goes out to the wrong person meanwhile.

When to escalate#

Escalate immediately if the message contained another customer's information. That is a disclosure and is handled as one: what was in it, who received it, and when, with the correlation id from the record. Escalate also if the recipient was on the suppression or do-not-contact list, since those are checked before sending and a send past one is a different failure from a mis-resolved identity.

Questions#

Related#

• Identities
• Merging two records
• What a merge preserves
• A duplicate record was created
• Telling a new prospect from an existing customer
• The reply went from the wrong address
• Troubleshooting