How do you keep a dropped call from creating two intake records?
Format: Article.
Keep a dropped call's session record separate from the business request it may relate to. When the caller reconnects, link the sessions only when the agreed evidence supports that link. Do not create a new request blindly, and do not merge people just because they share a phone number.
The design has two jobs. It must spot an event sent twice. It must also work out whether a new call belongs with earlier work. These are different checks. This is a proposed custom design. It is not proof that Core Agentic or your customer record system already supports it.
Use three levels of identity
A provider call identifier refers to a call. An intake session refers to the conversation state your application tracks. A business request refers to the work staff need to review. One request may have more than one call, while one caller may have several unrelated requests.
Twilio gives each call a unique ID, called a SID. It also records a parent call SID when one call creates another call leg.[3] A leg is one part of a phone connection. These IDs help trace related calls in the phone system. They do not prove that a new call is about the same request or that the caller may see old details.
Ask which IDs the phone provider supplies and which your CRM can store. A CRM holds customer records. It may not support links between call sessions or a unique key for each request. Check those limits before choosing the design. “Deduplication” means spotting or handling copies. Ask what the feature actually does, not just what it is called.
Proposed session-linking rules
| Incoming evidence | Proposed handling | What must not happen |
|---|---|---|
| Same provider event received again | Recognize the already handled event within the approved design | Create another business request for the same event. |
| New call with caller-supplied prior reference | Locate a candidate under the approved access process | Read private details aloud before authority is established. |
| New call from the same number, no reference | Treat earlier sessions as possible matches only | Merge automatically based on the number. |
| Conflicting name, request, or branch | Keep separate pending human review | Overwrite the earlier request to make the records fit. |
| Earlier save outcome unknown | Reconcile with the target system before creating again | Retry blindly and produce two cases. |
A link should be reversible. Preserve the original session references and the reason for the link. If staff later discover a bad match, they need to separate the records without losing either caller's account of events.
Hold uncertain matches in a review queue
Show the reviewer both session references, the facts that match, and the facts that conflict. State the proposed action. Show only data that this reviewer may see. Do not let them view another customer's or branch's private records just to make matching easier.
Staff can link to an existing request, create a separate one, or hold the case while they check. Save the reviewer's choice and reason. A score for how closely two records match should not make that choice on its own.
The spoken message should also respect uncertainty. “I can ask the team to check whether this relates to your earlier call” is safer than “I found your account” when the match is not established. A caller who says the earlier call was unrelated must not be forced into a merge.
Test a reconnect without hiding the gap
In a hypothetical proposed design, a caller starts a request about a service visit. The line drops before the return contact is confirmed. The intake keeps a partial session with that field marked unresolved.
The caller phones again from a shared office line. Another person used the same number earlier that day. The proposed system does not read either record aloud. It asks whether the caller has an approved reference and follows the company's identity and access process.
If the match is not clear, keep the new session separate and flag it for review. Staff check the facts they may access and decide whether to link it. A request can refer to both sessions. But joining them does not confirm the contact details that were unclear in the first call.
Run the reconnect test cases
Rehearse a same-number call about a new issue, a different-number call about the same issue, and two people calling from one office. Add a delayed event from the first call after the second has begun. The newer confirmed information should not be overwritten by an older partial result.
Also simulate a saved request whose success response is lost. Staff should be able to locate the original before retrying. Test what happens when that check is unavailable: the state should remain uncertain, not become “saved” or “not saved” by guesswork.
Bring your dropped-call cases to Core Agentic. Book a Demo to discuss a custom design. First, we need to check provider access, your CRM's limits, and the rules your team approves for linking calls. This is not a claim that those links have been built.
Sources
- Twilio: Call resource | Twilio.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.