The same person is being chased repeatedly
Duplicate protection catches one shape only: the same due moment for the same person. Three commitments an hour apart are three different rows, all valid, and each executes. Repeated chasing is nearly always several honest follow-ups rather than one row running twice, and the fix is a stop for that person or that thread rather than a bug report.
How it looks from both ends#
From inside the workspace, the follow-ups screen shows several open rows against one person, each with a plausible reason and a different due moment. From outside, the person has received two or three approaches about roughly the same thing, possibly on different channels, and has started saying so.
That asymmetry is the whole problem. Every row is individually correct — somebody or something committed to it, with a reason — and the harm is only visible when you look at the person rather than at the queue. The person's timeline is the view that shows it, because it puts the approaches in one column in the order the recipient met them.
Where the extra commitments come from#
| Source | Why duplicate protection allows it | Tell |
|---|---|---|
| Two people scheduled a chase | Different due moments, so not duplicates | Two rows with different reasons in the same wording |
| A person and the Assistant both scheduled one | Same reason, different moment | One row created by a person, one by create_followup |
| A call and an email each produced one | Different threads, one person | Two rows, two channels, one relationship |
| A merge brought both sides' rows over | Merging preserves follow-ups from both records | The extra rows appeared at the moment of the merge, not before |
A task row and a sending row for the same promise | One is work for a person, one is a message | The person gets chased and then chased again by hand |
What duplicate protection actually covers#
One rule, stated plainly: a follow-up with the same *when* for the same person is a duplicate and is not created twice. It is deliberately narrow because the alternative is a system that refuses a genuine second commitment — the call you promised on Tuesday and the email you promised on Friday are two promises, and collapsing them would drop one.
So the protection stops the accident of scheduling the same thing twice in one motion, and does not attempt to judge whether two commitments a day apart mean the same thing. That judgement belongs to a person looking at the relationship, which is why the stop controls are on the person and the thread rather than on the row.
What Connect did complete#
- Every commitment was recorded with a reason, and executed under the same gates any other follow-up passes.
- Each message or call is on the person's timeline with its outcome, so the pattern is reconstructable.
- Duplicate protection did its one job: no row ran twice for the same person at the same moment.
- A merge, if there was one, preserved both records' follow-ups exactly as it is designed to.
What Connect did not complete#
- It did not judge that several separate commitments amounted to over-contacting one person; that is not a rule it holds.
- It did not consolidate two chases on different channels into one approach.
- It did not stop the later rows once the earlier one was answered, unless somebody stopped them for the thread or the person.
- Nothing was suppressed automatically. Being chased too often is not the same signal as an unsubscribe, and Connect does not infer one from the other.
Stopping it now, and stopping it recurring#
Open the person, not the queue, and read the timeline.
Result You see what the recipient actually received, in order, across every channel — which is the only view where over-contacting is visible at all.
Stop the remaining commitments for that thread, or for that person if the whole relationship should go quiet.
Result Open rows close together rather than one at a time, and nothing new drains against them.
Cancel with a reason rather than deleting, and keep the one chase that still makes sense.
Result The record shows a decision was taken. A row that simply vanishes teaches the next person nothing.
If the person asked not to be contacted, record that as suppression rather than as a cancelled follow-up.
Result It binds every future attempt on that address, including ones created by the Assistant, instead of only these rows.
After a merge, the survivor's follow-up list is the first thing to read. Two records became one and their commitments came with them, so the minute after a merge is the cheapest moment to cancel the ones that are now the same promise twice.
When to escalate#
Escalate when one follow-up row shows more than one execution on the timeline, when rows reappear after being cancelled, or when a chase reaches an address that carries a do-not-contact entry. Those three are the shapes that are not explained by several honest commitments, and each of them is worth a proper look. Repetition on its own is a rules and habits question, and the answer is upstream of the queue.
Questions#
Why did duplicate protection not catch two chases one hour apart?
Because they are not duplicates by the rule Connect holds: the check is the same due moment for the same person. Two moments an hour apart are two commitments, and refusing the second would silently drop a real promise.
Do merged records double up on follow-ups?
They can. A merge preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides on purpose. Read the survivor's open follow-ups straight afterwards and cancel the ones that now say the same thing twice.
Will suppressing the contact stop existing follow-ups?
It stops them executing: a suppressed recipient causes a refusal at the gate, with the suppression named on the row. The rows themselves remain until somebody cancels them, so do both if the queue should also look right.