Better Travel Time Workflow
The Travel time feature is okay but it can be much better. A few people added some of the things that will make it better but there is a lot more needed.
1) Ability to set a default location for every hour of every day (separately). This way, I am in the office most Wednesdays and Thursdays I can set it to my offices location but the other days I can set to my home location
2) Add a travel time to the office for the days I will be in the office based on my schedule without an appointment. This will block that time out for appointments.
3) Ability to change the location of a certain time period, so if I work in the Manhattan office one day I can use that location for that day
4) Add a list of Frequent locations to make this changing easier
5) Travel time in the future should be based on your location for that time (including if you had an appointment, and its location) to give you an idea of travel time but appointments coming up today should be based on your current location
This would put the travel time on steroids.
Addition: Option to adjust the colour of the event.
Log in to comment and vote
Comments11
Trevin Chow
Feb 10, 2025
I love the potential of this workflow but it's not really meeting the mark.
My requests:
Ability to set a minimum travel time. Eg. Minimum of 30 mins otherwise use the exact travel time.
Ability to set a minimum travel time and an option to round to it nearest 5 mins? It seems a little insane to have 18 mins of travel time for example instead of 20 mins. As is, in my calendar I'll have "travel time" slots in my calendar that starts at say 8:12am.
Keywords in the event that could trigger a different behavior. E.g. if "#walk" is present, set it to walking mode for travel time vs a default of driving.
Daniel
Nov 14, 2024
Also, I am a little confused as to why this is only possible for big calendar integrations like Google or Apple. I am using Fruux (CalDAV) as my calendar which integrates seamlessly with Morgen overall but I cannot use the Travel Time feature with those although I can adjust locations in morgen for my events.
Oct 26, 2024
Danny Hatcher (Customer Support)
Oct 26, 2024
These are great suggestions and sound very similar to those in this request: https://morgen.canny.io/feature-requests/p/much-better-travel-time
Do you think I could merge these or is there something specific here that is different?
Signe
Oct 31, 2024
Danny Hatcher (Customer Support) merging would be great! Thank you! 😊 If possible, add the part about color (according to tag instead of calendar) to the request.
Signe Strøm Flugsrud (Signes Hundrastning)
Oct 26, 2024
Also - I'd love the option to have the travel time-events colored according to the main event's tag (instead of how they are currently colored according to which calendar the main event belongs to) 🙂
Ben
Oct 17, 2024
What is needed and make it worth to use an AI based agenda planner is when it does what a human does.
plan appointment and suggested appointment and with this take in account the locations with the previous location and the next appointment regardless the physical location. a api call is easy to do make the calculations even based on excepted travel time based on history.
AI has no added value when this is not possible and a human still needs to interfere to plan.
Also need to adjust meetings travel times based on deletion of changing.
To be able to reapply travel time to existing appointments a bug that us in Morgen prevent this to happen.
Overall that what is needed and why you want to have an AI planner that is missing in MORGEN. The capacity to do flexible scheduling and planning based on flexible physical locations and using different transportation items like but not limited to car, bus, truck, bicycle, public transportation and airplane. by bicycle and by foot is also needed due to many cities the car is not allowed to drive into anymore or by foot or bicycle is faster or the parking costs are high as like up to 50 euros per day or part of a day.
there are other development and they already are close to this.
x.ai I have used and this is not around anymore has been acquired and this had this and much more in to regarding planning.
Oct 9, 2024
Fade Rudman
Apr 20
•Merged request
•1 vote
Calculate Travel Time Based on Chained Event Locations, Not Just Home
When a user has multiple events at different locations throughout the day, travel time between consecutive events should be calculated from the previous event's location to the next event's location - not always from home.
Current Behavior: Travel time is calculated independently for each event, always routing from the user's home address. This produces incorrect durations and misplaced time blocks whenever the user is already away from home.
Requested Behavior: Morgen should treat the day's events as a location chain and calculate travel accordingly:
LegFromTo
1
Home
Event A location
2
Event A location
Event B location
3
Event B location
Home
This mirrors how a person actually moves through their day.
Concrete Example:
8:30 AM - 1:00 PM: Session in Location A (1:30 hrs from home)
1:00 PM: Coffee meeting in Location B (1:30 hrs from home, 20 minutes from location A)
The travel time between these two events should be calculated as Location 1 → Location B (a short drive), not Home → Location B (a much longer route that also produces incorrectly timed and positioned blocks in the calendar).
Why This Matters: For anyone with a multi-stop day, the current behavior makes the travel time feature unreliable - producing wrong durations, blocks placed mid-event, and duplicate time estimates. Chained location routing would make the feature genuinely useful for real-world scheduling.
Fade Rudman
Apr 21
Admins, those are five separate features. If prioritized together, they may not see the light of day in the upcoming year (and the issue is already one year old). Can we perhaps split it into 3-5, so that people can upvote what’s actually important for them, allowing for a shorter cycle for each?
Morgen Product Team
Apr 23
Thank you for sharing your thoughts.
Our development team take on larger projects at a time to try and stay focused, so splitting these requests would firstly hide them lower in the list, but also be harder to push through the development pipeline we have.
Grouping these together means a developer can work on them over a sprint, rather than trying to tackle lots of unrelated requests in 1 sprint.
However, I will pass this on to our development.
Thank you again for sharing!