Setting Up Time-Zone-Based Routing for a Shared Support Inbox
Front's rule engine can already route a shared inbox by time zone. A condition like "time is within business hours" or "time is between 09:00 and 17:00" checks a shared inbox's own configured hours, and an action reassigns or moves the conversation into whichever region's queue is currently live, per Front's guide to rule triggers, conditions, and actions. Business hours are set per shared inbox rather than only per workspace, so a follow-the-sun team can give its Manila, Berlin, and Austin inboxes three separate clocks and route on which one is open, per Front's business hours settings.
What doesn't travel automatically is a summary of what already happened. The full message thread moves with the conversation wherever a rule sends it, so nothing a customer already wrote is lost in any literal sense. What's missing is the layer above the thread: a note saying what the last shift already tried, promised, or ruled out, so the next person doesn't have to re-read the whole history or ask the customer to repeat themselves. Front's rules can post that note as an internal comment automatically, but only if a team builds the habit of writing one into the handoff, and that habit is the part that breaks first.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe mechanism: business hours and custom fields, not teammate names
Front's rules follow a trigger, condition, action shape: something happens, a set of conditions gets checked, and a set of actions fires. Under the "If" side, the time-based conditions include "time is within business hours," "time is outside business hours," and "time is between" a custom window with its own time zone selection, compared against the workspace's or the specific shared inbox's configured hours. On the "Then" side, the relevant actions are assigning a conversation to a teammate or a team (with round robin or load balancing across multiple people), moving it to a different inbox, and posting an internal comment that can @mention someone directly.
A Front community thread from a client-services team running SLA coverage across time zones lays out a pattern worth copying. The team runs 27 time-zone-specific inboxes split across 12 teammate groups, with routing driven by custom fields like "Time Zone Inbox" and "CSM Backup" rather than by naming individual teammates inside each rule. The reasoning holds up on its own: swap the field's value when someone changes territory or a new hire joins a region, and every rule that reads that field points at the right group, no rule edits required. The same thread also runs a second rule that mirrors each conversation into a shared team queue while it stays in its own region's inbox, so a manager can see everything in flight across regions from one place.
Building the rule: one condition per shift window
The setup itself is a handful of pieces per region:
- A shared inbox with its own business hours, one per region, so "business hours" means something different for Manila than it does for Berlin.
- A custom field that names the active region on the conversation or account, populated by the rule rather than hardcoded into it, matching the pattern from the community thread above.
- A rule per handoff window: when a new message arrives (or an existing one goes unanswered past a threshold) and the receiving region's business hours condition is true, assign to that region's team with round robin, and update the region field.
- An internal-comment action attached to the same rule, prompting whoever is closing out their shift to note status before the reassignment fires.
That last piece is the one that actually addresses the "losing context" half of the question, and it's also the one Front's rule engine can't enforce. A rule can trigger a comment box to open or a template to populate; it can't force the outgoing teammate to type something true and useful into it before moving on.
What happened at Anders Optical when the comment box stayed empty
Anders Optical sells prescription eyewear online to customers across North America and Europe, with a five-person support team split across a Berlin shift and an Austin shift, handing off through Front twice a day. Beatriz Coutinho runs support operations there and built the routing rule described above months before the gap showed up.
A customer in Frankfurt wrote in about a delayed prescription verification just before the Berlin shift ended. The Berlin teammate confirmed the prescription had been received and was queued with the lab, replied to say so, and the conversation sat open past the business-hours cutoff. Front's rule reassigned it to Austin on schedule. Nobody had filled in the internal comment field the rule made available, because the reply to the customer already said what mattered, or so it seemed at the time.
Customer, replying the next morning: Following up again, has my prescription actually been sent to the lab yet?
Austin teammate, before finding the earlier reply: Let me check on that for you, one moment.
The Austin teammate had the full thread in front of them and still spent two minutes scrolling to find Berlin's confirmation, because nothing marked it as the answer that mattered versus the rest of the back-and-forth. Beatriz's fix wasn't a new rule. It was a one-line internal comment template, "handoff: what's confirmed, what's pending, what the customer is waiting on," attached to the same reassignment action, so the box in front of the outgoing teammate asked a specific question instead of sitting there optional and easy to skip.
Where the rule-and-habit setup stops working
The fix above holds for a while, and it has predictable edges:
- The habit erodes under volume. A template makes the comment easier to write; it doesn't make anyone write it on the fortieth handoff of a busy shift, and the first skipped one is invisible until a customer repeats a question.
- More regions means more rules, and rules are plan-limited. Front's Starter plan caps out at 10 rules and Professional at 20; a follow-the-sun setup already needs one rule per handoff window plus a mirror rule per region, so that count can hit the ceiling before headcount does, per Front's pricing page.
- Nothing here stitches channels together. The handoff note lives inside one Front conversation. If the same customer also messaged a different regional inbox last month, or filed a complaint in a community Slack, the rule and the comment habit have no way of knowing that, because a routing rule only ever evaluates the conversation object in front of it.
- The rule graph grows with every new region or team. Twelve teammate groups across 27 inboxes, the shape in the community thread above, is already a lot of custom-field and rule maintenance for one company; each additional territory adds to it permanently.
Where Modem picks up the piece that doesn't scale
Past that point, the problem isn't routing anymore. It's that the record of what's already been said lives in whichever teammate remembered to write it down, on whichever conversation happened to receive it. Modem doesn't touch Front's rules, business hours, or assignment logic; a follow-the-sun team still needs those to get a message to the right region's queue at the right hour. What Modem's email integration adds is a dedicated inbound address that forwarded mail lands in alongside a team's other channels, matching people across those channels by sender address so a customer's history stays attached to one profile no matter which inbox or which shift touched it last. Opening that profile shows the prior exchange whether or not anyone left an internal comment about it, because the record isn't the comment, it's the topic itself. Since Modem's plans price by usage rather than by seat, adding every regional teammate to that view doesn't change what the team pays.
For the piece of this problem that lives entirely inside Front, routing support emails when the ownership data lives outside your inbox covers the same rule-and-custom-field mechanism applied to a different routing question, and applying tags retroactively to old support emails in Front covers what happens when a rule's reach stops at the moment it was created.
The smallest version worth trying first
Pick the one recurring handoff that generates the most repeat questions, whichever region-to-region transition it is, and add a single required internal-comment field to that reassignment rule before touching anything else. If the next shift still has to ask the customer to repeat themselves after that, the gap isn't the habit anymore, and that's the point to look at something that keeps the record outside any one person's memory of a shift that already ended.
