Orbit knows when to hand a call to your team, and when your team isn't there to take it.
Blackstar Systems' Orbit treats a transfer request as a time-gated handoff, not as a scheduling workflow. It checks the deployment's supported hours before connecting the caller, and outside those hours it says the person or department is not available instead of attempting a dead-end transfer.
Not every caller wants Orbit; some want a specific person. When that request comes in, Orbit checks the current time against that deployment's supported hours before doing anything else. Within supported hours, it connects the caller to the requested person or department. Outside supported hours, it says so plainly instead of attempting a transfer that has nowhere to go.
Key Facts
- Transfer behavior is configured per deployment.
- Orbit checks supported hours before trying to connect the caller.
- Within supported hours, it can connect callers to the requested person or department.
- Outside supported hours, it declines plainly rather than implying someone is available.
A transfer request is not a booking request.
A caller asking for a specific person or department is a different situation from a caller asking to book an appointment. There's no availability to check, no patient to identify, no record to write. The only thing that has to be resolved is whether someone is actually there to take the call right now, and that answer depends entirely on the time.
Orbit's role here is narrow, the same way it is everywhere else: recognize what's being asked for, check it against how that specific deployment defines being open, and act accordingly. It does not guess based on a typical schedule, and it does not treat a transfer request the same way regardless of when the call comes in.
Supported hours decide whether a transfer is attempted.
When a caller asks to be connected to a person or department, Orbit first identifies the request as a transfer, not a scheduling or lookup workflow. It then checks the current time against the supported hours configured for that deployment, specifically, not a general assumption about when dental practices tend to be open.
If the request falls within supported hours, Orbit connects the caller to the requested person or department directly. If it falls outside supported hours, Orbit tells the caller plainly that the person they're looking for isn't available right now, rather than attempting a transfer that would ring out or leaving the impression that someone is coming to the phone. Exactly what Orbit says in either case, and which people or departments are reachable at all, is configured per client.
Orbit does not imply a person is available when the time check says otherwise.
Orbit does not attempt to transfer a caller outside that deployment's supported hours.
It does not tell a caller someone is available when the time check says otherwise.
It does not guess at a practice's hours; it uses the specific supported hours configured for that deployment.
A transfer request is not a failed workflow, and it is not routed through the same escalation path used when a workflow can't complete safely.
Time checks keep a requested handoff from becoming a dead end.
A caller who asks for a person and gets silence, or a transfer that rings into nothing, has no way to know what happened. Checking the time before attempting a transfer, and saying so clearly when no one's there, is what keeps that request from becoming a dead end. It also keeps Orbit in its actual role: backing up the team that's there, not standing in for someone who isn't.
Common questions about call routing and transfers.
Does Orbit transfer calls after hours?
No. Orbit checks the supported hours configured for that deployment before attempting the handoff. Outside supported hours, it tells the caller the requested person or department is not available.
Is a transfer request handled like a failed booking workflow?
No. A transfer request is a time-gated handoff. It does not use the same recovery path as a scheduling workflow that cannot verify patient identity, availability, or a write result.
See supported hours configured on a live deployment.
Review how transfer and hours configuration work on the Open Dental integration.