Async vs Video Visits: The Product Decision That Shapes Everything

Early telehealth companies tend to treat async versus video as a feature question. It isn't. It's the decision that determines your unit economics, your provider staffing model, how much software you have to build, and in some cases which states you can operate in at all.

Worth getting right before you build.

What each one actually is

Synchronous is a live consultation — video or phone, in real time, scheduled.

Asynchronous (often called store-and-forward) is the patient submitting information — a questionnaire, photos, history — that a provider reviews later and responds to without a live conversation.

Most mature companies end up with both. But which one you lead with shapes everything else.

The economics are genuinely different

This is the part that surprises founders.

Synchronous is bounded by provider hours. A provider does maybe 12 to 20 video consults in a day. Your capacity is headcount times hours, full stop. Growth means hiring, and hiring providers is slow because credentialing and licensing take months.

Asynchronous is bounded by review throughput, which is much higher. A provider reviewing structured intake can handle many multiples of what they'd manage in live visits, because there's no scheduling overhead, no waiting, no small talk, and no context switching between calls.

That difference flows straight into your pricing. Async models can sustainably charge less per interaction because the provider cost per interaction is lower. If you're competing against an async competitor on price with a video-only model, you will lose that fight on structure, not execution.

The counterweight: async front-loads engineering. You're building the intake logic, the review queue, the provider tooling, the messaging layer. Synchronous can genuinely launch on a scheduling tool and a video platform, which is why it's the faster path to a first patient.

What the rules allow

Here's where it gets genuinely constrained, and where you need real advice rather than a blog post.

State rules differ on what constitutes a valid patient relationship and what modality is acceptable to establish one. Some states are permissive about async for establishing care; others require a synchronous interaction first, at least for certain treatments.

Prescribing adds another layer. Rules around remote prescribing — and particularly controlled substances — have been in flux and have specific requirements about the nature of the examination.

The practical consequence: your modality choice can determine your addressable map. An async-only model may simply not be available in some states for some treatments.

What to do about it: get a state-by-state matrix from counsel early, before you build. Then build the system so the modality can vary by state, because it will have to. Hardcoding "async" as a global assumption is a rebuild waiting to happen.

Patient experience cuts both ways

Async is more convenient, and convenience converts. No appointment, no waiting room, no needing to be somewhere at 2pm. Patients complete it at 11pm from their sofa. For routine, well-understood, low-complexity care, this is genuinely better for the patient.

Synchronous builds more trust, especially for anything the patient is anxious about, anything complex, and anything where they have questions they don't know how to ask in a form. Some people simply won't accept care from someone they haven't spoken to.

The pattern that works for most companies: async as the default for routine and repeat care, with synchronous available on request and required for the cases that warrant it.

What each one demands from your software

Synchronous needs:

• Scheduling that understands provider licensure by state, availability, and time zones
• Reliable video with a waiting room and a fallback to phone
• Documentation tooling providers can use during a call
• Reminders, because no-shows are expensive when the slot was reserved

Asynchronous needs:

• Intake with conditional logic, resumability, and good photo handling
• A provider review queue with sensible prioritisation and assignment
• Secure messaging with clear response-time commitments
• Escalation paths, so a case that needs a live conversation gets one
• Careful audit logging, since the clinical record is the artefact rather than the call

Async is more software. Budget accordingly.

The hybrid most companies land on

1. Async intake for everyone. Structured questions, photos, history. Cheap, scalable, and it means every synchronous visit starts with the provider already informed.
2. Async review for routine cases. Renewals, straightforward presentations, follow-ups.
3. Escalate to synchronous when the intake flags complexity, when state rules require it, or when the patient asks.
4. Async messaging for everything after. Refills, questions, check-ins.

This gets you async economics on the majority of volume while keeping the synchronous path for the cases and the states that need it.

How to decide

Lead async if: your care is routine and protocol-driven, your patients are price-sensitive, you need to scale beyond provider headcount, and your states and treatments allow it.

Lead synchronous if: your care involves genuine clinical judgement per case, your patients need reassurance to convert, your treatments require it, or you need to launch quickly with minimal engineering.

And build for both regardless, because you'll need the other one sooner than you think. The expensive mistake isn't choosing wrong — it's building a data model that assumes one modality and then discovering the other is mandatory in a state you wanted.

The one thing to get right on day one

Model the encounter generically.

Whatever you lead with, your data model should treat a "visit" as something that has a modality attribute, not as either an async submission or a video call specifically. Retrofitting the second modality onto a schema built for the first is one of the more painful migrations in this space, because it happens under live patient records.

---

We build both models and the intake, scheduling, and provider tooling behind them. See the telehealth build.