Latest / Marketing Automation with Fexingo: HubSpot, Marketo, and Automated Customer Journeys / How Marketing Automation Ignores Customer Time Zone Signals
Transcript
- Lucas: Let me ask you something — have you ever gotten a marketing email that says 'Good morning' and it's clearly the middle of the afternoon where you are? Luna: Oh, all the time. Especially from travel brands. I get a 'Rise and shine' from a hotel I stayed at, and it's 3 p.m. my time. Lucas: Right. And that's not just a minor annoyance — it's a genuine blind spot in marketing automation. Most workflows blast messages based on the sender's local time, or worse, the server's time zone. Which means a hotel chain based in New York might send its post-stay survey at 9 a.m. Eastern, landing at 6 a.m. Pacific, 2 p.m. in London, and 10 p.m. in Tokyo. Luna: So you're saying the automation is built for the company's convenience, not the customer's. Lucas: Exactly. And the data shows it matters. There's a mid-sized hotel group — about 80 properties globally — that looked at their post-stay email open rates and found they were averaging around 18 percent. They suspected timing was a factor, so they ran a test. Luna: What did they change? Lucas: They added a simple time zone lookup. When a guest checks in, the system captures their zip code or country code from the booking data. Then it maps that to a time zone — using a table, not GPS. And it schedules the post-stay survey to land at 10 a.m. in the guest's home time zone, not the hotel's. Luna: And the result? Lucas: Open rates jumped to 24 percent. That's a 34 percent relative lift — just from aligning the send time to the recipient's clock. Click-through rates on the survey link also went up, though not as dramatically. Luna: That's a huge win for a relatively simple fix. But I imagine not every platform makes it easy. Lucas: That's the problem. Most marketing automation platforms — HubSpot, Marketo, you name it — let you schedule sends by a fixed time, or by 'best time' based on aggregate open data. But they don't natively handle individual time zones unless you build it yourself. You need a custom field for the time zone offset, a workflow that looks up the offset from a lookup table, and then you schedule relative to that offset. Luna: So it's a data hygiene issue as much as a workflow issue. Lucas: Exactly. The first challenge is getting the time zone data. Some companies try IP geolocation, but that's often blocked on mobile browsers or VPNs. A better approach is using the time zone from the user's device if you can capture it — JavaScript has an Intl.DateTimeFormat API that returns the IANA time zone. But that only works on web forms, not email. Luna: And if you're collecting it at signup, you have to make sure it updates when people move. Because someone who signed up in Chicago might now be in Berlin. Lucas: Right. That's the second challenge — keeping it current. The hotel chain I mentioned only uses the guest's home time zone from the booking, which is a one-time snapshot. But if a guest moves, their time zone doesn't change for that trip. It's still accurate for that interaction. For a subscription business, though, you'd want to refresh it periodically. Luna: There's also daylight saving time. Some time zones don't observe it, and the offsets shift twice a year. If your lookup table isn't updated, you could be an hour off. Lucas: Good point. That's why using IANA time zone identifiers — like 'America/New_York' instead of just '-5' — is critical. The platforms can then handle DST shifts automatically if they support it. But most marketing automation databases don't have a native time zone type. You're storing a string and writing a custom script. Luna: And if these conversations have sparked something you've actually used at work — maybe you've tweaked a workflow or even just started thinking about timing differently — a couple of dollars a month is genuinely what keeps these going. Buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, it really does make a difference. No pressure, but listener support is what keeps this ad-free and focused on the details. Luna: Alright, back to time zones. Another layer I want to explore — what about mobile push notifications? They often bypass email time zone issues, but they have their own timing problems. Lucas: Absolutely. Push notifications are usually sent immediately or on a fixed schedule, and they don't respect the user's local time either. For a news app, that might be fine. But for a retail app sending a 'Your cart is waiting' message at 3 a.m. local time, it's a quick way to get your notifications disabled. Luna: So there's a parallel problem. But for push, you can usually get the device's time zone directly from the mobile SDK. That's easier than email. Lucas: True. For email, you're often stuck with what you can infer. But there's another technique: send-time optimization powered by machine learning. Platforms like Salesforce Marketing Cloud and some third-party tools can analyze each recipient's past open times and predict the best send window. That implicitly accounts for time zone, because the pattern reflects their local clock. Luna: But that requires enough historical data. For a new subscriber, you'd be guessing. Lucas: Exactly. So a hybrid approach makes sense: start with a time zone lookup for new contacts, then gradually switch to ml based optimization once you have engagement data. That way you're never sending blind. Luna: Let's talk about the financial impact. For the hotel chain, a 34 percent lift in open rates probably translated into more survey completions and more reviews. But what's the dollar value? Lucas: The hotel group told me that each completed survey added roughly $2.50 in incremental revenue from improved online reputation and repeat bookings. They were sending about 40,000 surveys per month. With the old 18 percent open rate, they got about 7,200 opens. With 24 percent, that's 9,600 opens. At a 30 percent click-through rate on the survey link, that's about 720 more completed surveys per month. Multiply by $2.50 — that's $1,800 a month, or about $21,600 a year. Luna: For a simple lookup table. That's a great ROI. Lucas: And that's just one campaign. The same logic applies to abandoned cart emails, re-engagement sequences, newsletter sends — any triggered message. The cost of the fix is essentially engineering time to set up the lookup and maintain the time zone table. Once it's running, it's almost zero ongoing cost. Luna: So why aren't more companies doing this? Is it just lack of awareness? Lucas: Partly. But also because the default in most platforms is so easy. You set a time, you hit activate, and you don't think about it. Time zone logic adds complexity — you have to create custom fields, map data, handle errors. For a global business, the effort is worth it. For a local business, it might not matter. But the problem is that many companies that think they're local actually have customers in multiple time zones. Luna: Even a coffee shop in downtown Chicago could have subscribers who moved to the West Coast and still get the emails. Lucas: Exactly. And that's the quiet danger. You don't notice the damage because you're not measuring opens by time zone. But the recipient does. They just start ignoring your emails. Luna: So the first step is auditing your automation to see when your messages actually land for different segments. If you're sending from Eastern Time, check your database for contacts in Pacific, Mountain, Central, and international zones. Lucas: That's a great takeaway. Run a simple export of your active contacts, group them by country or state, and compare that to your send schedule. If a significant chunk falls outside your 'ideal' send window, it's worth the engineering effort to fix it. Luna: And if you're using a platform like HubSpot, there are community-built workarounds — custom code actions that call a time zone API — but they require some technical know-how. Lucas: Right. For smaller teams, there are also third-party services that integrate with Zapier or Make to adjust send times. They'll look up the time zone and delay the email accordingly. It's not native, but it works. Luna: One more thing — what about transactional emails? Like booking confirmations or password resets. Those are usually sent immediately, and you probably don't want to delay them. Lucas: Transactional emails are time-sensitive, so you're right — delay is bad. But even there, you can time zone-optimize the content. A booking confirmation could say 'Your check-in is at 3 p.m. local time' and convert the time to the guest's home zone if you know it. That's a small touch that builds trust. Luna: So the theme is: respect the recipient's clock. It's a tiny data point that has an outsized impact on engagement. Lucas: Exactly. It's one of those things that seems obvious once you think about it, but most automation systems don't do it by default. And the companies that take the extra step get a real competitive advantage in inbox attention. Luna: All right, next time we should dig into how automation handles time zones across different calendar systems — like customers in countries that don't use the Gregorian calendar. That's a whole other layer. Lucas: That's a great angle. For now, I'd say the key takeaway is: check your send times. Even a basic time zone lookup can boost engagement more than most A/B test subjects you're running.