Twilio Softphone for Home Care Software
Building a Twilio Softphone Into SageCare AI's Home Care Platform
Client Overview
SageCare AI is an AI-native platform for senior home care agencies. Schedulers, intake coordinators, and back-office staff use it to manage caregivers, clients, and the constant stream of communication between them: the calls, the follow-ups, the documentation that has to happen after every one.
Impekable partnered with SageCare to design and build browser-based calling for senior home care teams, powered by the Twilio Voice SDK: a complete softphone experience embedded directly in the platform, covering everything from placing and receiving calls to number provisioning, team routing, and turning every conversation into part of the client record. The features described here are live in production.
The Problem: Senior Home Care Runs on the Phone
An intake coordinator fields a call from an adult daughter whose mother was just discharged from the hospital. A scheduler works down a list of six caregivers to fill a Tuesday morning shift. A care manager returns a voicemail about a billing question.
Before this work, none of that happened inside SageCare. Staff worked across a desk phone or a personal mobile, a separate contacts list, and the SageCare web app, then retyped what happened into a note, if they remembered to.
That split created four concrete problems:
Context died on the phone. The person on the call had the client's history open in one window and the conversation happening on an entirely different device. Nothing connected them.
Caller ID was a liability. Staff calling families from personal mobiles meant a family now had a coordinator's cell number. Calling from a generic office line meant families didn't recognize it and let it ring.
Documentation was manual and lossy. Call outcomes got retyped from memory after the fact, or never made it into the record at all.
Nobody knew who was reachable. A call would route to a coordinator who'd already left for the day, and it would just ring out.
The goal wasn't to bolt a dialer onto the side of the product. It was to make the phone a native part of the record.
What We Built
A Persistent Global Call Bar
The defining constraint of calling inside a web app is that a call outlives the page you started it on. A coordinator answers a call about a new client, then needs to pull up a care plan, check the schedule, and look up a caregiver, all while she's still talking.
We built the active call as a bar that spans the top of the application and survives navigation. It inverts to a dark surface so it reads as a distinct system layer, not page content, and it carries the caller's identity and line, a live duration timer, mute with a real-time mic-level meter (so a user can actually see their voice registering and answer "can you hear me?" without guessing), separate mic/speaker device pickers, hold that pauses recording and visibly changes state, a DTMF keypad, and recording status that's always visible.
A Pop-Out Call Window
For staff working across multiple tabs or a second monitor, the call pops out into its own always-on-top window.
This is the kind of feature that's simple to describe and genuinely hard to build correctly. The popped-out window and the main app stay in two-way sync through message passing: mute, hold, duration, and hang-up reflect instantly in both places, and closing either one resolves the call state correctly rather than leaving a phantom call behind. The main app collapses to a slim placeholder with a "focus main view" affordance, so the user is never confused about where their call went.
Choosing Which Number You Call From
Agencies provision multiple numbers: a main line, an intake line, individual staff lines. Before dialing, the user picks which one the recipient will see.
This piece took the most iteration, and it's the one that changed staff behavior the most. Our first version labeled this "Choose your outbound line." Tested against an actual coordinator, not a telecom admin, it read as jargon; nobody was confident what an "outbound line" even was. We changed it to "Which number will you call from?" and it clicked immediately.
That instinct, never let the software sound more technical than the job it's doing, carried through the rest of the interaction design: a chevron became the explicit word "Change," because a chevron reads as "go to another screen" and a verb reads as "you can edit this." Both the number being called and the number calling from display as a bold label first, then digits: Landline, 415 683 4971, so the part that matters is the part you read first. And the line selector sits directly on the dial screen, not hidden behind the call button, so you see your caller ID before you commit to it, not after.
Disambiguating Contacts With Multiple Numbers
Many contacts in senior home care have two numbers: a landline at the client's home and a mobile. Knowing which is which matters. You don't call a landline to reach someone who's out running errands, and you don't leave a voicemail on a mobile when the family checks the house phone.
We surfaced the line type consistently everywhere a number shows up: the contacts table, the call popover, the incoming-call screen, and the call detail record months later. We applied it across six separate views on purpose, because a labeling system that works in four places out of six is worse than one that doesn't exist. Users stop trusting it the moment it's inconsistent.
Receiving Calls
Inbound calls arrive in the same global bar, identified against the contacts database and matched to whichever line they dialed. We designed and built the full set of states a real phone system has to handle: a known caller with full identity and line context, an unknown caller with a path to create a contact directly from the call, call waiting with a clear answer-or-decline decision that doesn't risk dropping the live call, a clean resolution when the caller hangs up first, and, critically, a caught, recoverable state when no microphone is detected, before the user answers into a dead mic.
Browser calling fails in ways desk phones don't: permissions get denied, headsets get unplugged, the wrong input device gets selected silently. Every one of those is a moment where a coordinator is talking to a family member who can't hear her. We treated these as first-class design work, not error handling bolted on afterward.
Dialing Without Leaving Your Work
A search-and-dial module lives in the sidebar. Type a name to match against contacts, or type digits to reach a number that isn't in the system yet. It's fully keyboard-driven: arrow keys move through results, Enter dials the highlighted match, because the people using this are on the phone all day, and a mouse round-trip per call adds up. Call buttons also live directly on contact and entity pages for one-click dialing, and they disable automatically during an active call so staff can't accidentally start a second one.
The Call Becomes a Record
When a call ends, it doesn't disappear. The call detail view holds the participants (with their line labels intact), the recording with playback, and an AI-generated summary of what was discussed. The AI also proposes follow-up actions in the platform's own vocabulary: generate a care plan, send a follow-up email, create a client record, each moving through a clear proposed, accepted, or sent state.
The value here isn't that a call happened in a browser. It's that a five-minute conversation about a hip replacement recovery turns into a care plan draft and a client record without anyone retyping a word of it.
Availability That Actually Routes Calls
A toggle in the sidebar sets whether a staff member is reachable, and it feeds directly into the routing logic deciding what happens to an inbound call, not a cosmetic status indicator. A hover menu shows every line a staff member is assigned to, with individual toggles per line, synced in real time to the routing system.
Paired with it, we designed the fallback configuration: what happens when nobody picks up. Send to voicemail, forward to another line, or ring available teammates. Agencies configure this per line; staff can configure their own personal fallback from mobile. Per-line voicemail greeting management sits alongside it: upload a file or record one in-app through the browser mic, with playback and delete, and forwarded calls correctly play the greeting tied to the originally dialed number, not the line it landed on.
Number Provisioning and Administration
Behind the calling experience is the admin surface that makes it work: searching Twilio's available number inventory by area code or toll-free prefix, purchasing and configuring a number with webhooks set up automatically, assigning it to a team member, and releasing it back to the carrier when it's no longer needed. A multi-step provisioning wizard walks an admin through search, selection, team assignment, and a custom line name in one flow.
Release is irreversible and ends billing, so it requires typing the last four digits of the number to confirm. Deleted numbers stay visible in the table in a struck-through, clearly labeled state, rather than silently disappearing from the admin's mental model.
Before We Started
It's worth being specific about the baseline, because it's easy to underestimate how little existed before this project:
No calling of any kind inside the web platform. SageCare's iOS app had native calling, but web users had nothing.
No self-service number management. Acquiring or reconfiguring a phone number meant a manual Twilio console change or an engineering request, every time.
No concept of per-line availability or routing. A number either rang somewhere or it didn't; there was no system tying "is this person reachable right now" to what a call should do next.
No connection between a call and the client record. Whatever was discussed on a call lived only in whoever's memory took it.
Everything in this case study, the call bar, the routing, the provisioning, the record-keeping, was built from that starting point, not layered onto an existing calling feature.
Glossary: Terms Worth Knowing
Softphone. Software that replaces a physical desk phone, letting someone place and receive calls from an app instead of hardware.
WebRTC. The browser technology that makes real-time audio (and video) possible directly on a web page, without a plugin. It's what makes browser-based calling possible at all.
Twilio Voice SDK. The toolkit from Twilio, the telephony provider, that this feature is built on, handling the actual voice connection between the browser and the phone network.
TwiML. Twilio's markup language for telling the phone network what to do with a call, such as ring this number, play this message, or send to voicemail, generated dynamically here based on each org's routing configuration.
DTMF (Dual-Tone Multi-Frequency). The tones a phone makes when you press a number key (think automated phone menus: "press 1 for billing"). Needed for navigating phone trees during a live call.
Caller ID / line selection. Which of an agency's phone numbers shows up on the recipient's phone when staff place an outbound call.
Fallback routing. What happens to a call when the intended recipient doesn't answer: voicemail, forwarding, or ringing other available staff.
Idempotent operation. An operation safe to retry without causing duplicate effects. For example, retrying a failed number purchase without accidentally buying or billing for it twice.
Feature flag. A switch that lets a new feature be turned on for some users before a full release, so it can be validated in production before everyone sees it.
Design Approach
We Built on Their Design System, and Extended It
SageCare has a mature design language: sage green as the brand primary, a deep forest green for dark surfaces, cool zinc neutrals, and a three-family type system (DM Sans for display, Aeonik for UI, Inter for dense text and tables) on a strict 4pt grid.
Calling introduced UI patterns the system had never needed before: a persistent inverted system bar, live audio metering, device-selection popovers, incoming-call interrupts. We designed each as an extension of the existing language rather than an exception to it, the same radii, the same shadow treatment, the same restrained motion, the same sentence-case voice.
The Copy Is the Interface
The hardest problems on this project were consistently language problems, not visual ones. "Choose your outbound line" versus "Which number will you call from?" isn't a copywriting polish pass. It's the difference between a user who understands what she's about to do and one who's guessing. Same with a chevron becoming the word "Change." Same with labeling a number Landline instead of trusting someone to remember which one it is.
SageCare's design system is explicit on this point: address the user as "you," use sentence case, keep button copy to a short verb phrase, and never make the software sound more technical than the job it's doing. Holding to that made the product measurably easier to move through.
We Cut Features to Ship
Not everything designed made the first release. A call-quality indicator came out of the active call bar, and "ring all org members" came out of the fallback options, both added visual noise without earning their place in the initial launch. Deciding what not to ship was part of the work.
Under the Hood: The Twilio Integration
Twilio powers the platform’s calling experience, providing the infrastructure for both inbound and browser-based voice communications.
The integration allows calls to be intelligently routed based on business rules, user availability, and configured fallback options, while supporting AI-assisted call handling where appropriate. It also enables users to manage calls directly within the platform with a consistent experience across different workflows and screens.
Impekable designed the integration to feel seamless and reliable for end users while giving the organization flexibility to configure how calls are handled as its needs evolve.
A few architecture decisions were deliberate, not incidental:
Service-layer isolation. Twilio API interactions live in dedicated services, which keeps the integration testable and mockable rather than tangled through the UI layer.
Idempotent by default. Every provisioning and state-changing operation is safely retryable, necessary for handling network failures without creating duplicate charges or orphaned numbers.
Feature-flagged rollout. New calling functionality shipped behind flags for controlled deployment, with flags removed once validated in production.
Progressive enhancement. The web calling experience degrades gracefully with clear error states when devices are unavailable or permissions are denied, rather than failing silently.
One reliability improvement worth highlighting was strengthening the provisioning process to better handle partial failures and prevent incomplete system states.
We also added safeguards around migrations so changes can be reviewed and validated before being applied, helping reduce risk during rollout and giving teams more control over how updates are introduced.
Test coverage spans the admin provisioning flow, settings and integration views, the migration command, model behavior, the service layer, and the dialer component itself, the parts of the system where a quiet failure would show up as a dropped call or a missing invoice, not a visible bug.
Outcome
Web calling is live in SageCare AI. Agency staff place and receive calls from inside the platform, on lines the agency controls, with the client's full history on screen, and the call becomes part of that history automatically, without anyone retyping it.
The work spanned the full range: product definition, interaction design, visual design within an existing system, frontend implementation, telephony integration, and backend routing and reliability engineering.
Area | What Shipped |
|---|---|
Product Design | Web calling flows end to end, from dialing through active call to call record. Inbound call states for unknown callers, call waiting, and device failure. Admin surfaces for number provisioning, line configuration, fallback routing, and voicemail management. |
Design System | Extended SageCare's design language to cover real-time communication UI while staying consistent with existing mobile and web surfaces. |
Engineering | Browser calling client, persistent and pop-out call UI, Twilio integration, availability-aware inbound routing, number provisioning APIs with idempotent retry safety, voicemail storage and playback. |
Mobile | Companion screens for staff availability, personal fallback configuration, and voicemail greeting recording. |
Hear It From Ian Gillis, Co-Founder and CTO of SageCare
What We Learned
The hardest problems weren't technical, they were about naming things correctly. "Outbound line" versus "which number will you call from" is the clearest example, but it repeated everywhere: a chevron misread as navigation, a number with no label misread as ambiguous. Every one of those got caught by testing language against real coordinators, not by a design review.
Reliability work that never shows up in a demo matters just as much as the UI. The provisioning race condition, the idempotent retries, the migration dry-run, none of it is visible to a user having a good day. All of it is the difference between a smooth agency onboarding and a support ticket about a phone number that got charged for twice.
Consistency has to be enforced across every surface, not just the main one. The line-type labeling only became trustworthy once it existed in all six places a number appears: contacts table, call popover, incoming call, call detail, and beyond. A pattern that's reliable in most places trains users to stop trusting it everywhere.
Shipping less can be the right call. Pulling the call-quality indicator and "ring all org members" out of the initial release wasn't a compromise. It kept the first version focused on what agencies actually needed on day one.
The Takeaway
A phone system embedded in your software is only worth building if it does something a phone company's dial tone can't: connect a conversation to everything you already know about the person on the other end.
That's the real shift here. Not that calls happen in a browser now, but that a five-minute call about a hip replacement recovery turns into a care plan draft and a client record without anyone touching a keyboard. The phone stopped being a tool that lived next to the software. It became part of it.
