Frequently asked questions about the AI virtual receptionist

Run2AI Virtual Reception is an AI virtual receptionist for healthcare and veterinary facilities: it answers phone calls, WhatsApp messages, website chat and email, gives information, books, moves or cancels appointments when the practice software is integrated, logs callback requests and hands the conversation to a person when needed.

Run2AI works only in healthcare, and the conversation flow has been refined over about two years with facilities that use it every day. Run2AI is the brand of Run 2 Cloud S.r.l., a Milan-based company working in healthcare since 2016.

Its role is to take repetitive, organizational requests off the front-desk team, not to replace clinical judgment. The full product overview is on the AI Virtual Reception for healthcare page.

Virtual Reception works on four channels, namely phone, WhatsApp, website chat and email, and uses the same facility documentation for all of them: information updated once applies everywhere, and the facility can switch on only the channels it needs, for example starting with the phone and adding the others later.

• Phone: the main channel in healthcare, connected to the existing phone system.
• WhatsApp: on the facility's own number, with the same flow as the phone.
• Website chat: a small window on the site that answers questions and leads to booking.
• Email: draft replies that staff approve before sending.

Yes, Virtual Reception can answer 24 hours a day, seven days a week, including nights, weekends and public holidays, so even when the front desk is closed patients get information, book when the practice software is integrated or leave a callback request, and the facility decides which time slots it covers.

At first, many facilities use it mainly when the front desk is closed; extending it to other time slots is gradual and no phase is mandatory. When the facility reopens, the front desk finds callback requests in the panel with name, number and summary, ready to return.

Yes, during opening hours Virtual Reception transfers the call to a staff member when the patient asks for one or when the request genuinely needs a person, while outside opening hours it logs a callback request with name, number and a summary of the conversation, which the front desk finds in the control panel.

Callback requests work like a small ticketing system: yellow for open ones, green for patients already called back, with a record of who called back and when.

If the patient asks for someone by name or for a specific office, such as administration or billing, the bot routes the call to the right extension, respecting each person's or office's hours.

Virtual Reception answers from just two sources: the facility's documentation, organized into cards and chapters, and the services synced from the practice software with descriptions and preparation instructions; on day one, this information is extracted automatically from the website and existing documents, so nobody starts from a blank page.

• Documentation: opening hours, locations, parking, payments, insurance agreements and report turnaround times, which can differ by location.
• Services: imported from the practice software with a “sync” button, together with descriptions and preparation, with no double entry.

The facility then reviews the content, for example starting from its patient service charter, and keeps it up to date; staff are trained to do this during setup. The information applies on every channel. For a temporary campaign, it is enough to add a chapter and delete it when the campaign ends. Synonyms and colloquial names for services can be added too, so the bot understands a patient who asks for “a scan” rather than the exact service name.

If the information is not in the documentation, Virtual Reception does not make up an answer, because an orchestrator designed for healthcare workflows keeps it within the information the facility has entered: the bot tells the patient so and transfers the call to a staff member or, when the facility is closed, logs a callback request.

The unanswered question goes into “suggested additions”: every two weeks, or once a month, the facility reviews them and adds what is missing to the documentation. The aim is that questions such as opening hours or the email address stop interrupting staff.

In our experience, an estimated 20–30% of requests will always be so specific that they rightly go to a staff member.

The Virtual Reception control panel shows the phone calls, chats and WhatsApp conversations handled by the bot, with the outcome of each one by channel, such as bookings, callback requests and cancellations, plus the full transcript of every conversation, which also helps reconstruct what happened if a patient disputes something.

The panel also shows:

• calls that ended without a booking and questions left unanswered, to improve the documentation;
• administrator and user profiles, which can be limited to one or more locations;
• with a cloud phone system, the option to call the patient back straight from the panel.

With a VoIP or SIP phone system, Virtual Reception connects through a SIP trunk: a dedicated extension is created and the phone system routes calls to it according to rules set by the facility, while with an analog system a dedicated number is used together with call forwarding when nobody answers.

• VoIP/SIP phone system: already in use with widespread cloud systems such as 3CX. Transfers to staff go through a second “twin” extension: if the call came back to the original extension, it would end up with the bot again, in a loop.
• Analog phone system: a dedicated number plus call forwarding, so when nobody answers, the phone passes the call to the bot.
• Closed proprietary system: the facility can move to a VoIP provider, adopt a cloud phone system or start with call forwarding as a test.
• Mobile phones only: forwarding to the bot is switched on and off by hand, because there are no time-based rules.

Facilities without VoIP can be put in touch with Run2AI partners for a no-obligation quote.

The facility chooses which calls go to Virtual Reception through its phone system rules, because the bot only sees the calls it receives: most facilities start with after-hours calls and calls that come in when all staff are busy, and after the running-in period many make the bot the first point of contact around the clock.

In healthcare, calls arrive in peaks, such as between 8 and 10 in the morning or on Monday mornings: staffing for the peaks is impossible, while the bot absorbs the volume on its own. As the first point of contact, it passes to staff only what genuinely needs a person.

Inbound call handling is described on the AI inbound call management page.

Yes, Virtual Reception handles several conversations in parallel and there is no practical cap on simultaneous calls on Run2AI's side: the real limit is the number of lines on the facility's phone system, so with 12 lines the bot can hold up to 12 conversations at the same time.

That is what makes the bot useful during peaks such as Monday mornings: instead of a busy signal, the patient gets an answer even when every staff member is on the phone. To handle more conversations at once, the facility simply adds lines to its phone system.

Yes, when the practice software is integrated, Virtual Reception reads availability in real time, offers the patient the slots that are actually free and books, moves or cancels the appointment directly in the practice software, which remains the master system that services, prices, price lists and clinicians are synced from with a single button.

If the patient asks for a clinician by name, the bot searches only that clinician's calendars; otherwise it combines the availability of everyone who provides that service. After booking, whatever the practice software already does kicks in, such as SMS or email reminders. In Doctolib Vettore, bookings made by the bot arrive with a note showing where they came from.

Some platforms are closed ecosystems: there, the bot collects the request and passes it to staff. Without practice software, even with a simple or paper diary, the bot can work on Google Calendar or Outlook Calendar.

Virtual Reception integrates in real time with Doctolib Vettore, Caremed (Innogea), Alfadocs, DBMedica, Medinformatica Medistudio, Multimedia Medica Siomed, Bollino IT, BCS and RB Software Center Ges.La.An., as well as with Google Calendar and Outlook Calendar for facilities without practice software, and for veterinary clinics also with Snoots and Alcyon Dr.Vet.

With Doctolib without Vettore there is currently no real-time reading or writing of calendars: how it works is explained in the question about Doctolib.

The detail pages are Doctolib Vettore, Caremed, Alfadocs, DBMedica, Medinformatica Medistudio, Multimedia Medica Siomed, Bollino IT, BCS, RB Software Center Ges.La.An. and Google Calendar.

Run2AI Virtual Reception reads and writes Doctolib calendars in real time only through Doctolib Vettore, the practice software Doctolib has a partnership with, while with Doctolib without Vettore the bot answers patients' questions and collects the booking request for staff or directs the patient to the facility's online booking page.

Without Vettore, then, the bot does not see free slots and does not add appointments to the calendar: the callback request reaches the panel with name, number and summary, or the patient books on their own on the facility's online page, for example its Doctolib page.

Details are on the Doctolib Vettore and Doctolib pages.

For each service, location and payment route, the facility chooses how Virtual Reception behaves: in integrated mode it checks availability and books on its own, in to-be-handled mode it collects the request for staff, which helps with complex triage or several calendars at once, and in walk-in mode it only gives instructions.

In the panel, integrated services show in green and to-be-handled ones in yellow. When the price list calls for it, the bot asks for clarification, for example “a standard dermatology visit or one with dermoscopy?”, and reads the preparation instructions before offering dates. A typical service to hand over is surgery that needs both a surgeon and an anesthetist; a typical walk-in service is blood tests “Monday to Friday, 7:30–9:30, fasting”.

• Insurance: the bot asks for the insurer to check coverage.
• SSN (Italy's national health service): the route is active only where the facility is accredited and switched off where the regional booking center (CUP) handles bookings; when the month's budget runs out, the switch is turned off and the bot tells the patient.

Bookings under the Italian national health service are covered on the SSN/SSR booking page.

Yes, Virtual Reception is built for multiple locations: opening hours, addresses, unscheduled closures, information and services are set up for each site, and with one number per site the bot already knows where the call is coming from, while with a single central booking number it asks the patient which location they want.

Staff have an administrator or user profile and are assigned to one or more locations, so each person sees the requests for their own sites. The Pro plan adds unlimited users, advanced statistics and call routing to specific people or teams.

The cost per location falls as the number of locations grows. A second site that is only a blood-draw point on the same number can start as a single-site setup.

Yes, with the optional outbound calls module, Virtual Reception phones the patient a few days before the appointment, asks for confirmation and, if needed, moves or cancels it, with the outcome shown immediately in the panel and the freed slot available for the facility to give to another patient.

It is a real conversation, not a recorded message: “You have a full abdominal ultrasound the day after tomorrow, can you confirm?”, and the bot also answers the patient's questions. After two or three unanswered attempts, a WhatsApp message can follow. Appointments to call come from the practice software or from an imported file, for example only the patients who did not confirm by SMS.

Periodic recalls, such as a dental cleaning or a mole check every 12 months, need solid consent: for real campaigns, talk to the DPO and check the Italian opt-out register (Registro delle opposizioni). The module is described on the AI outbound call management page.

On the phone and on WhatsApp, Virtual Reception already knows the patient's number and, if patient records are synced with the practice software, recognizes the caller and asks for confirmation before booking, while it asks a new patient for first name, surname and Italian tax code letter by letter, checking it in real time.

The confirmation is explicit, along the lines of “Are you booking for Mario Rossi?”, and patients can also book for a child or a parent. If the tax code does not check out, the bot asks for date and place of birth and calculates it; if the patient is not on file, it creates the record in the practice software.

There are no side questions such as “how did you hear about us?”: the bot gets straight to the point.

Yes, Virtual Reception works well with elderly patients and regional accents: one of Run2AI's first clients is an eye clinic specializing in cataracts, with a very elderly patient base, where effectiveness matched that with younger patients, and facilities in Veneto, Sicily and Sardinia confirm that it copes well with local accents.

In our experience, around 95–98% of conversations go smoothly. In the 1–2% of difficult calls, which would be hard for a human operator too, the bot notices that the conversation is not moving forward and hands over to a person.

There is no “press 1” menu: patients speak normally, can interrupt and change topic, and the voice speed is tuned to be clear even for the oldest callers.

When a patient describes an emergency, such as needing to come in within half an hour because something serious has happened, Virtual Reception stops the routine booking, advises the emergency services (118 in Italy), the emergency room or coming to the facility, and, if configured, triggers an alert or transfers to staff at once.

The bot picks up the semantic cues of urgency in what the patient says. Like a human operator, though, it cannot guess an emergency the patient does not express. It does not go into the clinical details of symptoms: its job is to direct, not to assess.

No, Virtual Reception deals only with organizational and informational matters, such as opening hours, services, test preparation, bookings and callback requests, and offers no clinical or therapeutic advice: if a patient describes symptoms the bot does not go into them and, if an emergency emerges, it points to the emergency services (118 in Italy) or the emergency room.

Medical images are out of scope too: if a photo of a prescription or a skin lesion arrives on WhatsApp, the bot stops and hands the conversation to a person. This boundary keeps patients safe and protects the facility.

On WhatsApp, Virtual Reception acts as the first point of contact on the facility's own number, even a landline, with the same information and flow as on the phone: it answers questions, books when the practice software is integrated, logs callback requests and transcribes voice messages, which staff can still listen to.

If a photo arrives, such as a handwritten prescription or a picture of a lesion, the bot stops because it does not analyze medical images: the front desk gets an email notification, opens the conversation and replies person to person.

Under a Meta rule, after 24 hours of silence the facility can write first only with an approved template message, which can be sent from the panel with one button. Details are on the WhatsApp for medical centers page.

The phone remains the main channel in healthcare, but on websites with good traffic we estimate that the Virtual Reception chatbot ends up handling 20–30% of conversations, because many people do not browse the detail pages and prefer to ask their question directly in the chat.

The chatbot is installed on the site as a small window and uses the same information as the other channels. To book, it can work just as it does on the phone when the practice software is integrated, or take the patient to the online booking page, such as the Doctolib portal. If the site gets little traffic, it is better to start with the phone.

Yes, email is the newest and least used of the four channels: for each message, Virtual Reception prepares a draft reply with the information it knows and staff decide whether to send, edit or discard it, while on specific topics the bot can reply automatically without going through staff.

It makes sense mainly when a facility receives many repetitive emails, such as questions about opening hours or preparation instructions. For booking, the phone, WhatsApp and chat are better suited.

Yes, Virtual Reception suits polyclinics, dental practices, eye clinics, diagnostic centers, physiotherapy centers and dermatology clinics, that is, facilities with many repetitive calls and services to book, and each of these specialties has a dedicated page with examples, typical services and sector-specific questions.

The examples change more than the way it works: in a diagnostic center, test preparation and payment routes matter most, in a dental practice regular check-ups, and in an eye clinic a patient base that is often elderly.

The pages are polyclinics, dental clinics, eye clinics, diagnostic centers, physiotherapy and dermatology.

Yes, Virtual Reception also suits veterinary clinics and pharmacies: it answers pet owners and pharmacy customers in the same way it works for healthcare facilities and, in veterinary practices, it can integrate with sector software such as Snoots and Alcyon Dr.Vet to read availability and book appointments.

Independent healthcare professionals are also covered, including psychologists, nutritionists and osteopaths. The dedicated pages are veterinary centers and pharmacies.

Yes, and it is an increasingly common case: for a general practitioner, Virtual Reception acts as a filter, answering questions on opening hours, how to access the practice and prescriptions, directing emergencies to the emergency services (118 in Italy) and turning everything else into orderly requests handled when the practice has time, without promising immediate availability.

Repeat prescriptions for long-term treatments go into a dedicated list. If the practice only uses mobile phones, forwarding to the bot is switched on and off by hand. Several GPs working together, for example in an Italian AFT group of primary care doctors, can share the same solution and split the cost.

Yes, Virtual Reception processes patient data in line with the GDPR: the bot always introduces itself as a virtual assistant and refers to the facility's privacy notice, no AI model is trained on patient conversations, and Run2AI signs a data processing agreement with the facility, acting as its data processor.

Run2AI gives the facility's DPO a dedicated information notice and documentation on server compliance, so the privacy assessment starts from concrete documents.

Data processed by Virtual Reception is stored on Google Cloud Platform in Europe and the AI models also run in Europe, while the retention period is chosen by the facility, for example one, two or three months, after which the data is deleted automatically.

Conversations and transcripts are encrypted at rest and can be read in clear text only by people who log in to the panel with their own credentials. Audio recordings of calls follow a separate, stricter rule, with a maximum of seven days.

Audio recordings of calls handled by the virtual reception service are kept only for technical checks and troubleshooting, for the time strictly needed for that work and in any case no longer than seven days from the call date, after which they are deleted automatically.

Only the authorized technical lead can listen to them. For day-to-day work, the facility uses the written transcript of each conversation, available in the panel.

Run2AI Virtual Reception is priced modularly: the phone channel starts at €224 per month, which is an annual fee of €2,690 excluding VAT, plus a one-off setup cost and any usage above the included allowance, and the facility switches on only the channels and modules it needs.

• One-off setup: configuration, testing and staff training on the documentation and the panel.
• Fee: annual or quarterly, for the active channels and modules.
• Usage: only above the allowance included in the fee.

The practice-software integration is charged at a flat rate, so the price is fixed in advance. A facility can start with a single location or a single channel and expand later. The full quote comes in the first call with the Run2AI team. All prices exclude VAT.

The phone channel fee includes 500 minutes of actual conversation per month, about 350 calls, and beyond that allowance billing is per minute, counting only calls that reach the bot: in our experience 30–40% of clients pay nothing for usage and about 40% spend a few tens of euros a month.

Clients that send tens of thousands of calls to the bot spend a few hundred euros a month, against thousands of bookings. On WhatsApp, usage costs a few cents per session: we estimate it rarely exceeds about ten euros a month. Zero usage costs are typical of facilities that use the bot after hours and at peak times, staying within the allowance.

An example, as an estimate: 3,000 calls a month with a 15% conversion rate mean about 450 bookings; at an average value of €80, that is about €36,000 booked per month and, with a 10% margin, about €3,600 in margin. The usage cost stays in the order of one tenth of the margin generated.

Yes, the first step is free: the demo number published on the website, +39 02 3055 1707, answers just as Virtual Reception would answer patients and can be called at any time, including by colleagues and partners, followed by a test environment where test calls appear in the panel in real time.

• Pilot: at a single location or on the voice channel only, even just after hours.
• Three-month trial: paid, to verify results; it usually covers the voice channel and callback requests.
• Running-in: the documentation is enriched, then the scope widens until the bot becomes the first point of contact.

Fees can also be paid quarterly. The demo number is also on the AI Virtual Reception page.

Setting up Virtual Reception usually takes two to three weeks, and in the fastest cases the facility is live in five or six days, because telephony, practice-software integration and content preparation run in parallel and the work starts from a base already tested in similar facilities.

• Telephony: call transfer set up with whoever manages the phone system, then testing.
• Practice software: calendar integration and syncing of services and clinicians.
• Content: documentation drawn from the website, the patient service charter, other files and preparation instructions; this is the longest part.

Staff training is included. It is also possible to start with a pilot at a single location and extend later.

With an IVR, patients press keys in a rigid menu, whereas with Virtual Reception they speak normally and the bot understands the request, books when the practice software is integrated and transfers the call to a person when needed; the VoIP or traditional phone system remains the line the AI receptionist sits on.

A longer comparison is in the article IVR and Virtual Reception.

In healthcare, the hard part is not turning speech into text but guiding the patient through ambiguous service names, payment routes, preparation, locations and clinicians, so a generic bot ends up passing everything to staff, while Virtual Reception is built around these workflows and stays within the facility's own information.

A typical example is “MRI of the right knee, high-field, without contrast”: to book it, the bot has to identify the right service in the price list, the payment route, the preparation and the correct calendar. Several facilities came to Run2AI after trying generic answering services or outsourced call centers.

No, Virtual Reception does not replace staff but frees them up: front-desk teams also handle check-in, payments and paperwork and are constantly interrupted by the phone, so the bot takes the standard requests and people keep complex bookings, personalized questions and welcoming patients in person.

At peak times, many facilities end up silencing the phone. Some keep headcount unchanged for the first 6–8 months of running-in. The bot is most useful when growth starts to strain the team, with three people too few and four too many: we estimate that one extra hire costs about €40,000 a year, while the bot absorbs the extra volume without a step change in costs.

Facilities that had outsourced calls to a call center often report inaccurate information and wrong bookings; the bot uses only the facility's own information and calendars.