Clinics
A reception desk that puts nobody on hold.
In a polyclinic, reception has three lines, a counter with people standing at it, and an appointment list that changes in real time. The call ringing for the fourth time is the one that goes to another clinic. The assistant takes the administrative half of those calls, and only that half.
The assistant books by speciality and by doctor from the clinic calendar, reads test-preparation instructions out of your own documents, moves or cancels appointments, and passes anything about a patient condition to reception. Clinical triage stays entirely with clinic staff.
What it lifts off the three lines
The useful split in a clinic is not between simple and complicated calls, but between administrative and clinical ones. The assistant takes the first kind, in full, and does not touch the second.
Booking by speciality
The caller says which speciality they need, and the assistant offers the free slots of the doctors in it.
Preparation instructions
How many hours of fasting before a test, whether water is allowed, what to bring to a scan. The answer comes from the clinic documents, not from general knowledge.
Rescheduling and cancelling
It finds the appointment by phone number and moves or deletes it, freeing the slot in the calendar.
Cover and paperwork
Which insurers the clinic works with and what documents to bring, from the list you keep current.
Day-before confirmations
A short campaign that dials tomorrow appointments and marks who is coming, who is moving and who did not answer.
What a booking looks like end to end
Every step below uses a tool that exists in the product today. Where the knowledge base appears, that means documents you uploaded, indexed in Postgres with pgvector.
- 01 Establish the speciality The first question separates speciality and preferred doctor. If the caller describes a symptom instead of a speciality, the assistant does not interpret it: it offers reception.
- 02 Search the calendar It calls the availability tool against the doctor calendar, through Google Calendar or Outlook Calendar, and offers real times.
- 03 Read the preparation For tests and imaging it queries the knowledge base. If no suitable passage is found, the product writes a knowledge-insufficient event on the call and the assistant says it does not know, rather than inventing.
- 04 Create the appointment The event goes into the calendar with name, phone, speciality and any preparation note, and the caller gets an SMS confirmation.
- 05 Hand over what is not its business Results, interpretations, treatment changes and anything that sounds urgent go to reception or the clinical queue, with the context so far carried across.
What gets written, and where
In a clinic, what is not written down did not happen. The rows below are written by tools, at the time of the call.
| In the doctor calendar | The appointment, with speciality, phone number and preparation notes in the description. |
|---|---|
| By SMS | The confirmation with date, time, doctor and the preparation instruction, when there is one. |
| In your own records | A row in Google Sheets or Airtable, or a ticket, if you prefer to track administrative calls as tickets. |
| On the call record | The transcript, the tools called, the knowledge-insufficient event when it occurs, and the structured output with speciality and outcome. |
What it does not do for a clinic
This list matters more here than anywhere else on the site. A clinic carries obligations a software vendor cannot take over, and this product is not built to take them over.
- No triage and no medical direction It does not say how urgent a symptom is, which speciality a pain belongs to, and it does not comment on a result. It is not a medical device and has not been assessed as one.
- It does not give out results It does not read test results down the phone and does not verify a patient identity to the standard that would require. Result requests go to reception.
- No link to your clinical system There is no ready-made connector for the practice-management systems used by Romanian clinics. The link to yours is an HTTP tool over your API or an MCP server, which is development work, not a checkbox.
- It does not handle insurance settlement It does not file, validate or check anybody entitlement. It can only read back what you wrote in a document.
- No outcome data from a real clinic We have not run the product in a polyclinic at volume. What has happened so far, failed calls included, is on the status page.
What clinics ask us
Can it book across several doctors in the same speciality?
Yes, if each doctor has their own calendar connected. The assistant checks availability across the calendars in the requested speciality and offers the earliest free slots. The rule it uses to pick a doctor, when the caller has no preference, is something you write in the assistant prompt.
How does it know the preparation for a test?
From your knowledge base. You upload the clinic documents, they are chunked and indexed with pgvector in Postgres, and retrieval combines vector similarity with Postgres full-text search. You can also put the assistant in knowledge-only mode so it answers from nothing else.
What happens if somebody describes a serious symptom?
The assistant does not assess severity. It is configured to recognise a set of phrases you define and transfer immediately, with no further questions. That is not triage, it is word matching, and the difference matters.
Is it compliant with medical data rules?
Compliance belongs to the clinic, not to us, and that cannot be delegated by contract. What we provide are the means: recordings can be written straight into your own storage, the retention period is configurable, and the recording announcement the caller hears is written by you. The security page states what we do and do not guarantee.
How long until it works?
An assistant that books against a calendar takes an afternoon, following the first-assistant and phone-number guides. What takes longer is the second half: the preparation documents and the transfer rules, which are written together with reception, because reception knows what is actually asked.
Where to go next
Integrations
25 business connectors, 18 selectable providers, eight storage destinations.
Knowledge base
Upload, chunking, vectors in Postgres, and knowledge-only mode.
Telephony
Numbers, trunks, dial plan, queues, operators and campaigns, in one system.
Pricing
Components at their published price, the platform on top, and what we cannot price yet.
Notes
-
1
The tools named on this page are the ones in
App\Services\Integrations\ConnectorRegistrycarryingimplemented. Anything that is only in the catalogue, without that flag, is not named here as though it worked. - 2 Knowledge-only mode and the knowledge-insufficient event are described in the knowledge-base guide. Indexing runs on Postgres with pgvector, and embeddings currently go through OpenAI only.