Been looking at how softphones integrate with CRMs lately, and it's a nice example of an old idea getting genuinely more capable once you add AI to it. The old idea is the "screen pop", a call comes in, and the CRM record for that caller pops up on screen. Contact centers have done a version of this for decades.
What's changed is what happens around the pop now. Sharing some notes, because the plumbing turns out to be more involved than "match a number to a record", and the AI part adds a whole second half.
The classic screen pop, and its limits
The traditional flow is simple in concept. Call arrives, you've got the caller's number from the signaling, you look that number up in the CRM, you surface the matching record. Done.
In practice even that has rough edges. The number might not match cleanly (formatting, country codes, extensions). The caller might have multiple records, or none. The number might be a shared line. So even "classic" screen pop has a matching-and-disambiguation problem underneath it. But once solved, it's genuinely useful: the agent sees who's calling before they answer.
The limit is that it's read-only and one-shot. It shows you the record at the moment of the call and does nothing else. Everything after, logging the call, updating the record, capturing what was said, is still manual.
Where AI changes the shape of it
The interesting shift is that AI makes the integration bidirectional and continuous, not just a read at call-start.
Context injection, richer than a record lookup:
Instead of just popping the raw CRM record, you can feed the caller's history (recent deals, last conversation, open tickets) into an assistant that gives the agent a useful synthesis, or answers questions against that history live during the call. That's a different data flow than a screen pop: you're pulling structured CRM data and putting it in front of a model as context, mid-call.
Write-back, automatically
This is the bigger change. When the call ends, the AI has a transcript and can generate a summary, and that summary gets pushed back into the CRM as a note or activity on the contact. The integration stopped being read-only. Now it writes.
That write-back is where a lot of the actual engineering lives, and it's easy to underestimate.
The write-back problem is trickier than it looks
Pushing an AI summary into a CRM sounds like one API call. It usually isn't that clean.
You have to attach the note to the right entity, which contact, which deal, which ticket, and that's the same disambiguation problem from the screen pop, except now you're writing, so getting it wrong actually corrupts data rather than just showing the wrong screen. You have to map your summary structure onto whatever the CRM's data model expects (custom fields, activity types, required properties). You have to handle the CRM being down, or rate-limiting you, without losing the summary, so you need queuing and retry. And you want it idempotent, because retrying a failed write shouldn't create three copies of the same note.
None of that is exotic, but it's real integration work, and it's the difference between "logs summaries reliably" and "logs summaries usually, and occasionally onto the wrong contact."
Multiple CRMs, one integration surface
The other thing that shows up fast: businesses use different CRMs. HubSpot, Zoho, Pipedrive, Salesforce, whatever. If you hardwire to one, you've limited your addressable market to that CRM's users.
So the sensible design is an abstraction over "CRM" as a concept, lookup a contact, fetch history, write an activity, with per-provider adapters behind it. Same pattern as abstracting a model provider or a payment provider: define the operations you need, implement them per backend, keep the calling code provider-agnostic. It's more work upfront and much less work per new CRM you add.
If you want to see the range of tools a softphone ends up integrating with in practice (CRMs, helpdesks, and the rest), this overview of enterprise tool integrations gives a decent sense of the surface area you're designing against.
Why I think this is a good example
The screen pop is a decades-old feature, and it would have been easy to assume it was a solved, boring problem. AI didn't just add a shiny feature next to it, it changed the shape of the integration, from a one-shot read into a continuous, bidirectional flow with real data-integrity concerns on the write side.
That's a pattern I think shows up a lot with AI features generally: the flashy capability (an assistant, a summary) is the visible part, but the interesting engineering is in the unglamorous plumbing that makes it reliable, the matching, the mapping, the retry logic, the abstraction over providers. Get the plumbing right and the AI feels magic. Get it wrong and it writes a summary onto the wrong customer.
Anyone here built CRM write-back for AI-generated content? Curious how you handled the entity-matching-on-write problem specifically, since writing to the wrong record is a lot worse than reading the wrong one, and it seems like the place this gets genuinely hard.
Top comments (0)