One inbox, many sites. Describe your locations and Taskade Genesis builds a booking desk where every request lands in a single queue tagged with its site, routes to the team that covers it, and rolls up into one view so you can see which locations are full and which have room.
The Room Booking Dashboard is a live Taskade Genesis app on this page. It already keeps several bookable places in one view, which is the multi-site problem in miniature; press "Use this app" to clone it in about ten seconds, then add the location field, the per-site routing, and the shared queue described below.
Multi-site businesses usually end up with one booking system per site, which works until someone asks a question that spans them. Which location is busiest on Saturdays. Where should the new hire go. Why does one shop have a three-week wait while another has gaps. None of those are answerable from four separate calendars, and all of them are obvious from one queue with a location field.
What the build gives you: a location record with team, opening hours, services offered, and capacity. Plus a single request form where the customer picks a site or is matched by postcode, automatic routing to the local team, per-site views for the people who only care about their own shop, a combined roll-up for you, and the ability to offer a customer a different site when theirs is full.
The same requests render across the layouts you need:
- Table view for every booking with its location, service, and status
- Board view grouped by location, so each team works its own column
- Calendar view filtered per site or across all of them at once
- Plus List, Mind Map, Gantt, and Org Chart across the rest of the 7 project views
Automations route without a switchboard. The Form Submitted trigger captures the request, an AI categorize step assigns a location from the address when the customer has not chosen one, and a filter notifies the right team channel. A scheduled trigger sends each site its day sheet and sends you the cross-site summary. Across 100+ bidirectional integrations, forms and Gmail pull requests in while Slack, SMS, and email push routing out. Automations run on paid plans; the Free plan includes 10 flow runs in total.
The AI agents in the app carry 34 built-in tools including persistent memory and multi-agent collaboration. The Desk agent suggests an alternative site when the requested one is full, keeps the confirmation wording consistent across every location, and flags when one site's wait time has drifted well beyond the others.
Offering an alternative site is the feature that pays for the whole build. A customer told "we are full for three weeks" leaves. A customer told "we are full here, but our other shop, eleven minutes away, can see you on Thursday" often takes it. That offer is only possible when both sites are in the same queue.
Consistency is the second benefit and the quieter one. When each location writes its own confirmations and applies its own cancellation rules, customers who use two of your sites notice, and it reads as disorganization. Shared templates and shared policy fields fix it without a training programme.
Clone the app, invite each site team, and give everyone the view they need. Roles run from Owner through Viewer, so a site manager can run their own column without touching another location's bookings.
Learn categorization in Learn, table layouts in Learn, and app users in Learn. Browse live builds in the Community Gallery. Pair this with the request and confirm form as the underlying flow, and the booking revenue report to compare sites properly.
Frequently Asked Questions
Can each site see only its own bookings?
Yes. Filter each team's view to their location while the underlying queue stays shared. Roles run from Owner through Viewer, so a site manager can work their own column without editing another shop's records.
How does a request get assigned to a location?
The customer picks one, or the app assigns it from their address. Letting the customer choose is usually better, because people have preferences about which branch they use that a postcode cannot see.
Can we send a customer to a different site?
Yes, and it is the most valuable thing this build does. When their preferred location is full, the app offers the nearest site with room, which saves bookings that would otherwise walk away.
Do all locations have to offer the same services?
No. Services offered live on the location record, so the request form only shows what that site actually does, and routing never sends a request somewhere it cannot be fulfilled.
Can each site have its own hours and capacity?
Yes. Opening hours and capacity are fields on the location, which is what makes the cross-site comparison meaningful rather than misleading.
How do we keep confirmations consistent?
Shared message templates with location merge fields. Every site sends the same well-written confirmation with its own address and phone number filled in.
Can we compare performance across sites?
Yes. Bookings, wait time, no-show rate, and utilization per location sit in one Table view, which is a far more honest comparison than four separate reports produced differently.
Does this scale to a lot of locations?
Yes. Location is just a field, so ten sites work the same way as two. The thing that scales badly is separate systems per site, which is exactly what this build replaces.
