Last verified: October 5, 2026
What You Can Now Do
Context Memo now rings discovery calls through to real phone numbers instead of filtering legitimate callers out as junk. If you book a discovery call, the call connects. Before this change, the screening logic in our Twilio webhook handler was too aggressive: it treated genuine inbound discovery traffic the same way it treated spam, so calls that should have reached a real person were dropped before anyone picked up. The screening is still there, but it now distinguishes between a legitimate caller and actual spam traffic. The practical change for you: you no longer need to confirm a discovery call over email after the fact, or follow up to ask whether the call went through. If the call was booked, it rings.
Where It Is in Context Memo
This lives in the discovery call system, not in a screen you configure. The change sits in two places in the codebase: the Twilio webhook handler that receives inbound calls, and the core discovery call logic that decides whether a call connects or gets screened. There is no new setting, toggle, or dashboard panel to visit. Discovery call scheduling and records remain where they were in your account; the behavior behind them is what changed.
How to Use It
- Book or accept a discovery call as you normally would. Nothing in the booking flow changed.
- Make sure the phone number on the booking is a real, reachable line. The handler now routes to that number directly, so an unreachable or placeholder number is the one remaining failure mode.
- Take the call at the scheduled time. The call rings through on the number provided rather than terminating at the screening layer.
- If a call still does not connect, note the time and the originating number and send both to us. With the new logic, a blocked legitimate call is a reportable defect, not expected behavior, and the originating number is what we need to trace it through the webhook logs.
- Confirm on your side that spam calls are still being screened. The filter was narrowed, not removed. If junk traffic starts reaching you, that is also worth reporting.
Why We Built It
Customers told us discovery calls were being blocked or filtered incorrectly, and legitimate outreach was not reaching the people it was meant to reach. The cost was direct: a booked call that never rang, with no signal to either party that anything had failed. The person expecting the call assumed no one dialed. The person dialing assumed no one answered. Neither was true, and the conversation simply did not happen. For a workflow where the entire point is getting a real person on the phone, a screening layer that cannot tell a buyer from a robodialer is worse than no screening at all.
What It Does Not Do Yet
The screening decision is made server-side, and you cannot currently see or adjust the logic from your account. There is no allowlist you can edit, no per-number override, and no log view that shows you which calls were screened and why. If you need that level of control today, the workable approach is to report specific numbers to us so we can verify them against the handler's behavior directly.
The change also does not alter how calls are recorded, transcribed, or attributed. Discovery call records behave exactly as they did before; only the connection path changed.
Reliability work like this is unglamorous, and it rarely appears in a feature list. It matters anyway. The rest of what we do depends on calls, alerts, and webhooks firing when they are supposed to. A scan that identifies a competitor getting cited instead of you is worth nothing if the conversation about what to publish never happens because the phone did not ring.