A member calls one number. Her appointment comes back booked.

She picks Thursday at 2:30. Both sides hear it from the same source.

The assistant contacts Midtown Family Medicine again, this time to confirm under Maria's name, using that office's preferred channel. Then the record goes back to PROVIO, where your billing, services and member confirmation flow take over.

Nobody on your staff touched it. Billing and eligibility questions, and anything outside booking, are handed to your team with a summary. The assistant gives no medical advice; an emergency gets a 911 instruction and a flag to your team.

Under the hood

Five named parts. The two in the middle are ours to run; the outside ones are the same vendors behind our live receptionist today. Your platform sits on the right as the system of record. Nothing clinical crosses the dashed line.

Why these parts

• Vapi runs the voice: it hears, speaks, dials, and hands structured results to our service during and after each call. It is what answers our live demo line today.
• Twilio sends the texts from a registered business sender, so confirmations reach members instead of a spam folder, and your numbers port with you.
• Our booking service holds the conversation logic, the 36 provider profiles, and the retry rules. It's written by Bartlett Labs in TypeScript, the same code base as our receptionist, so the member line and the office calls share one brain.
• Postgres is a standard relational database; any developer can read it, and your data exports cleanly.
• PROVIO stays the system of record. We feed it; we don't replace it.

For your developer

Everything above comes down to two questions about pro.myprovio.com: can we read a member by phone number, and can we post a booking back? Three paths, from best to simplest. We start on whichever fits this month and move up when ready.

What we send on path 1

Each event is a signed JSON POST to a URL you give us, with a shared secret in the header, an event id so your receiver can ignore duplicates, and a retry if your side returns an error. All times are ISO 8601 in Central Time. Field names are a starting point; we match your schema.

POST https://pro.myprovio.com/hooks/bartlett   (your URL)
X-Signature: sha256=…                           (shared secret)

{
  "event": "booking.confirmed",
  "request_id": "req_8f2c1a",
  "member_id": "mbr_10442",
  "provider_id": "prv_017",
  "start_time": "2026-10-29T14:30:00-05:00",
  "service_type": "primary_care",
  "confirmed_via": "phone",
  "office_contact": "front desk, Midtown Family Medicine",
  "summary": "Confirmed Thursday 2:30 PM with Dr. Lin. Member texted the details."
}

What we need to read from PROVIO

• Member record by phone number: id, name, mobile, employer, eligibility, home address, work address, preferred language if you capture it, and whether the member agreed to texts (when and how). Carriers require that record before we text a member.
• Provider roster: practice name and address, scheduling phone, contracted services, front-desk hours, booking rules, preferred contact channel.
• A sandbox or test account for week 1, and a way to post to a test member before any live member data is used.

Data handling, in one place

• Booking data only: identity, location, service type, timing. Callers who start describing a condition are steered back to scheduling. Nothing clinical is stored.
• Recordings: member calls kept 30 days by default, limited to booking details, or off. Provider-call recording can be disabled.
• Vendor agreements, including any required Business Associate Agreements with the voice and messaging vendors, are settled in week 1 before live member data. The assistant identifies itself as PROVIO's scheduling assistant on every call.
• PROVIO owns its rosters, call logs, transcripts and booking history. Full export on request, including at cancellation. The booking number is yours and ports with you.
• Hosting: Bartlett Labs servers in Dallas, Texas, encrypted in transit and at rest, nightly backups, uptime monitoring with alerts to us.