A scheduled visit depends on more than an open time
A dental schedule combines provider availability, operatories, visit types, appointment length, office hours, and exceptions the front desk handles from experience. EigenH needs those rules before it should act on a patient’s request.
We start by mapping what the agent may complete, what it may offer, and what must go to staff. The goal is a clear appointment outcome, not automation for its own sake.
The rules your team can define
- Providers and hygienists
- Operatories and other constrained resources
- Visit types and duration
- New-patient and existing-patient workflows
- Office hours and after-hours behavior
- Rescheduling and cancellation conditions
- Requests that require a staff handoff
- Confirmation and follow-up steps
The practice remains responsible for the rules and the schedule source used in the deployment.
What happens during a patient call
1. EigenH identifies the request
The patient may want a new visit, a different time, a cancellation, or help from the office. EigenH captures the intent before taking action.
2. The approved scheduling rules are checked
EigenH uses the schedule source and connection approved for the deployment. It considers the relevant provider, operatory, visit type, timing, and other conditions together.
3. The request is completed or handed off
If the request fits the approved workflow, EigenH records the appointment outcome. If it falls outside the rules, staff receive the reason and available context.
4. The team can review what happened
The front desk should be able to see whether the request was scheduled, rescheduled, cancelled, or sent for review.
Integration claims stay tied to product reality
Dental practices use different practice-management systems and configurations. We do not treat a planned connector as a live one.
During evaluation, we label the required connection as:
- Available: ready for the approved production workflow
- Pilot: being used in a limited, reviewed deployment
- Planned: on the product roadmap but not ready for production use
- Custom: requires a scoped implementation and technical review
Any named integration on the site should carry one of these labels after the product owner confirms its status.
The schedule remains understandable to staff
Automation should not create a second version of the truth. Before launch, the practice and EigenH agree on:
- Which system controls availability
- Where completed appointment actions are written
- How conflicts or failed updates appear
- Which actions require staff validation
- How changes and cancellations reach the team
Test routine cases and exceptions
A workflow is not ready because one ideal appointment request worked. We validate common requests, after-hours behavior, unavailable options, changes, cancellations, and staff handoffs before production use.
Can EigenH connect to our practice-management system?
It depends on the system, required actions, and deployment stage. Tell us what you use and what the agent needs to do. We will confirm the current availability label before proposing the workflow.
Can staff control which appointments EigenH handles?
Yes. The practice defines the visit types, timing, resources, and exceptions the agent may handle.
What happens if a schedule update fails?
The workflow should surface the failure and send the request to staff. EigenH should not tell a patient an appointment is complete when the approved schedule source did not accept the action.