Hi everyone,
I’m looking for the most reliable way to route callers based on business hours without a massive delay at the start of the call.
What I’ve attempted so far:
-
Logic Split Node (Internal Variables): I first tried using a Logic Split node with equations like {{current_hour_24_America/Vancouver}}. However, I found this inconsistent—sometimes the variables didn’t seem to parse as expected, or the logic didn’t fire reliably, leading to routing errors.
-
Custom Function (n8n): To get 100% logical accuracy, I moved the check to an external n8n workflow.
-
The agent calls a POST webhook to n8n.
-
n8n runs a JS script and returns {"is_open": true/false}.
-
Retell stores this as a variable and uses a Logic Split to branch the call.
The Problem: While the n8n method is logically perfect, it has introduced a 12-second delay. I have “Speak during execution” turned OFF and “Wait for result” turned ON. The caller sits in total silence for 12 seconds before Emma starts speaking, which is a poor user experience.
Questions:
-
For those using the Logic Split Node successfully, what is the “gold standard” equation for checking hours that won’t fail or hallucinate?
-
Is there a way to “warm up” or optimize Custom Functions to get that 12-second round-trip down to 1–2 seconds?
-
Does using a self-hosted n8n instance typically cause this much overhead compared to Retell’s internal processing?
I’m trying to find the balance between the speed of internal variables and the reliability of a hardcoded JS function. Any advice would be appreciated!
Based on the sources, here’s how to reliably route calls based on business hours using Logic Split Nodes:
Recommended Equation-Based Approach
For time-based routing with Logic Split Nodes, use equation-based transitions rather than prompt-based ones(1). The recommended format is:
{{current_hour}} >= 8 AND {{current_hour}} < 17
(1)
This approach provides more reliable results than prompt-based conditions because it removes LLM interpretation from the equation(1).
Critical Implementation Details
Explicitly Define the Else Clause: Community members have found that explicitly stating the else transition is essential for Logic Split Nodes to work consistently(2). Without this, the node may get stuck or fail to route properly(2).
Use Clear Instructions: Instead of just using “else,” provide sentence-based instructions to the LLM as if instructing a human(2). For example: “transition if {{current_time}} is between 8am and 4pm PST”(2).
Timezone Considerations: The {{current_time}} variable defaults to PST (America/Los_Angeles)(2). You can use timezone-specific variables like {{current_time_America/Vancouver}} for other timezones(3).
Logic Split Node Behavior
Logic Split Nodes evaluate conditions immediately upon entry with minimal time spent in the node(4). The agent does not speak in this node, and transition happens instantly when the agent enters(4). This makes them ideal for routing without introducing delay(4).
Alternative: Inbound Webhook Approach
If you need 100% reliability without any LLM interpretation, the inbound webhook approach is recommended(5). The webhook fires before the call even starts (while the phone is ringing), so it doesn’t affect latency(5). This allows you to run your business hours logic on your server and either reject the call before it connects or send a variable to your prompt(5).
Your 12-second delay with the Custom Function approach suggests the function is being called during the conversation flow rather than at call initialization. Using the inbound webhook instead would eliminate this delay entirely since the logic runs before the call connects(5).
**