The case for commute-aware scheduling

Here’s a situation that happens to operators in every major city, every day.

You have a meeting at 2pm in Leblon. It ends at 2:45pm. Your calendar shows you’re free. Someone proposes a 3pm meeting in Barra. You accept because 3pm looks available.

Then reality hits. It’s a Wednesday afternoon. The drive from Leblon to Barra takes 47 minutes in traffic. You’ll arrive at 3:32pm at the earliest. But your calendar doesn’t know about traffic. It doesn’t know about geography. It shows a grid of time blocks. In that grid, 3pm is empty. So 3pm gets filled.

Now you have three bad options: be 30 minutes late, cancel one of the meetings, or attempt a dangerous rush through traffic. None of these options would exist if your scheduling tool understood the physical world.

Every scheduling tool on the market treats time as one-dimensional. You’re either “free” or “busy.” There is no concept of where you are, where you need to be, or how long it takes to get between them. This is an absurd limitation for anyone who doesn’t spend their entire day in front of a laptop.

The physical world still exists

The remote work era created an illusion that scheduling is purely a time problem. For many knowledge workers who operate entirely from home, it is. But for operators, founders, investors, and anyone whose role involves physical presence, the world outside the screen is the constraint.

A founder who has a board meeting downtown at 10am, school pickup at 3:30pm in the suburbs, and a dinner meeting at 7pm across town is navigating a logistics problem, not just a scheduling problem. The question isn’t “am I free at 3pm?” It’s “given where I’ll be at 2:45pm, where I need to be at 3:30pm, and what the traffic conditions are at 3pm on a Wednesday, what is physically possible?”

This is a question that no calendar app asks. But it’s the question that determines whether your day works.

The problem is especially acute in cities with unpredictable traffic patterns. In Sao Paulo, a cross-city drive can take 20 minutes at 10am and 90 minutes at 5pm. In Los Angeles, a 15-mile drive during rush hour can exceed an hour. In London, the difference between tube and taxi at peak hours is the difference between 25 minutes and 55 minutes.

Operators in these cities have learned, through painful experience, to build mental buffers. “I know that meeting is in Centro, so I need to leave Barra by 1pm.” But these mental buffers are imprecise, inconsistent, and invisible to anyone else scheduling on their calendar.

What commute-aware scheduling looks like

A commute-aware scheduling system would integrate three data sources that currently live in separate silos.

Your calendar (where your meetings are). Every event has a location, explicit or inferred. A Zoom link means you’re at a screen. A restaurant name means you’re at a physical location. “Office” means your workplace. The system needs to know where each event places you physically.

A maps API (how long it takes to get between locations). Google Maps Directions API provides drive time with real-time and predictive traffic data. For transit-heavy cities, it provides public transport estimates. For walkable distances, it provides walking time. The API can estimate travel time at specific departure times, accounting for typical traffic patterns.

Your scheduling rules (your constraints and preferences). Minimum buffer after travel. Preferred transportation modes. Maximum commute you’ll accept for a coffee meeting versus a board meeting. Time needed to settle in after arriving (you don’t want to walk into a negotiation sweating from a rush).

When someone proposes a 3pm meeting in Barra and you’re finishing at 2:45pm in Leblon, the system doesn’t show 3pm as “available.” It shows 3pm as “travel conflict” and suggests 3:45pm or 4pm instead. The suggestion accounts for drive time, traffic at that hour, and your preferred buffer.

This isn’t hypothetical technology. Every component exists. Maps APIs have provided traffic-aware route estimates for over a decade. Calendar APIs expose event locations. The integration layer is what’s missing.

The scheduling link problem

Scheduling links (Calendly, Cal.com, and similar tools) made this problem worse.

When you share a scheduling link, the tool shows the other party your “available” slots. Available is defined as: not occupied by another calendar event. There is no concept of where you’ll be before and after each slot.

The result: a scheduling link that shows you’re free at 3pm on Wednesday, when in reality you’ll be 45 minutes away from the proposed meeting location. The other party selects 3pm. You accept (or the system auto-accepts). The conflict isn’t discovered until the day of, when you realize the meeting is physically impossible.

This failure mode is embarrassing, unprofessional, and entirely preventable. A commute-aware scheduling link would only show slots that are physically reachable given your preceding event’s location and the proposed meeting location.

The hidden cost of ignoring commute

The immediate cost of commute-blind scheduling is obvious: late arrivals, canceled meetings, and stressful rushes through traffic. But there are subtler costs.

Wasted buffer time. Operators who know they have commute challenges over-buffer. They’ll leave 90 minutes between meetings that are 30 minutes apart by car, “just in case.” This over-buffering wastes time that could be used productively. If the system showed that the drive takes 25 minutes with typical traffic, a 40-minute buffer would suffice.

Suboptimal meeting clustering. Without commute awareness, meetings end up geographically scattered across the day. A downtown meeting at 10am, a suburban meeting at 1pm, another downtown meeting at 3pm. That’s two round trips that could have been one if the downtown meetings were consecutive.

A commute-aware system would suggest: “You have two meetings downtown on Wednesday. Would you like to cluster them? Moving the 3pm to 11:30am would eliminate one cross-city trip and save approximately 50 minutes.”

Energy drain from transit. Commuting is tiring. Not just because of the time it takes, but because of the cognitive load of navigating traffic, finding parking, dealing with delays, and managing the anxiety of potentially being late. This energy drain compounds across a day with multiple commute segments. An operator who drives 3 hours across a day of meetings arrives at each subsequent meeting with less energy than the last.

This is why many operators intuitively cluster their in-person days and keep other days remote. It’s an energy management strategy disguised as a scheduling preference. A system that made commute costs visible would help operators make this trade-off explicitly rather than intuitively.

Beyond driving: the multimodal reality

Commute-aware scheduling isn’t just about cars. Operators use multiple transportation modes, sometimes within a single day.

Walking between meetings in the same neighborhood. Subway across the city. Ride-share for late-night meetings when parking is difficult. Sometimes, a combination: drive to the train station, take the train downtown, walk to the meeting.

A truly commute-aware system would suggest the optimal mode for each segment: “For your 2pm in Centro, taking the metro from Botafogo is 28 minutes and avoids the 45-minute traffic on surface streets. You should leave by 1:25pm.”

The system doesn’t need to be prescriptive. It needs to be informative. Show the operator the real cost of each transition, in minutes and in recommended departure time, and let them decide.

The air travel extension

For operators who travel between cities, the commute-aware principle extends to air travel. A meeting in Sao Paulo at 9am when you’re in Rio de Janeiro the night before isn’t a scheduling problem. It’s a logistics problem.

The system needs to account for: flight options and departure times, travel time to the airport, recommended arrival buffer (domestic vs. international), travel time from the destination airport to the meeting location, and time zone differences.

An operator who schedules a 9am meeting in GRU while in GIG needs to know: the last viable flight is the 6am shuttle, which means leaving for Santos Dumont by 4:30am. Is that meeting worth a 4:30am departure? Maybe. But the operator should know the real cost before accepting.

This is why we built air travel awareness into the Executive tier. Operators at that level frequently navigate multi-city schedules where the difference between “available at 9am” and “actually able to be there at 9am” spans an airplane ride.

Scheduling in the physical world

The calendar was designed as a time management tool. For decades, that was sufficient. Most meetings happened in one building. The commute was the same every day. Location was a constant, and time was the variable.

That world is gone. Operators work from home offices, co-working spaces, coffee shops, client offices, airports, and everywhere in between. Location is now a variable, and it changes multiple times per day.

The tools haven’t caught up. Google Calendar was launched in 2006, optimized for a world where you sat at a desk and attended meetings in a conference room down the hall. Twenty years later, the core model hasn’t changed. You’re still “free” or “busy,” with no concept of where in the physical world you happen to be.

Scheduling in the physical world requires a new primitive: not just time availability, but spatial availability. Not just “when are you free?” but “when can you physically be at this location, given where you’ll be before and after?”

It’s a harder problem than time-only scheduling. It requires real-time data, predictive modeling, and an understanding of the operator’s physical context. But it’s a solvable problem. And solving it eliminates an entire category of daily friction that operators currently manage with mental math, over-buffering, and occasional embarrassment.

Your calendar should know where you are. It’s 2026. This shouldn’t still be a radical idea.

---

Tact integrates Google Maps to calculate real commute times between your meetings, suggests realistic scheduling, and blocks travel time automatically. Because “free at 3pm” should mean you can actually be there at 3pm. Learn more at usetact.io

---