Scheduled tasks5
Automate recurring workplace tasks. Pick a task to get started.
- New hire desk assignment
Seat new hires near their manager and team, with a daily assignment report.
Set up a scheduled task named "New hire desk assignment". - Schedule: [RUN TIME], my time. - Connectors for its runs: Robin (Workplace), plus Slack if the report goes to Slack. - Notifications: [NOTIFICATIONS] when a run finishes. - First check my scheduled tasks. If another task already seats new employees, show it to me and ask whether to replace it, so two tasks don't seat the same people. - Check that I have planning access to the buildings in scope. Tell me any I don't, since runs can't seat people there. - After creating it, tell me its approval setting. Runs only seat people and publish when the task approves automatically. Use this as the task's prompt: Seat new employees at permanent assigned desks in Robin. Use the Robin (Workplace) connector. Don't ask questions; nobody is watching this run. Call scenario_planning_workflow first and follow it, except where these steps say otherwise. Scope: [BUILDINGS]. Who needs a desk 1. find_people with addedWithinDays [LOOKBACK DAYS], paging through every result. Keep statuses ACTIVE and ADDED (added but not signed in yet). 2. Skip [SKIP]. 3. get_draft_assignments for everyone left, in batches. Anyone who already holds a desk anywhere is done. Count who still needs a desk before changing anything. Choosing desks 4. A free desk is one find_desks lists with isDisabled false, assigneeCount 0 and deskTypes exactly ["assigned","shared"]. Never convert a desk's type, never move or unassign anyone who is already seated, and never use the same desk twice in a run. 5. For each person, try these in order and take the first that has a free desk in scope: a. Next to their manager: get_draft_assignments for the manager, then a free desk in the manager's pod, then the same neighborhood, then the same floor. b. Where their teammates sit: find_people with managerIds set to their manager, get_draft_assignments for those teammates, then a free desk on the floor where most of them sit, their pod first. c. Their department's neighborhood: get_building_overview with includeNeighborhoods, then a free desk in a neighborhood whose name or description matches their department. Department names are free text, so match case and spelling loosely. d. Any free assigned desk in scope, starting with the building that has the most free assigned desks. 6. When several new people share a manager, seat them next to each other. Write a one-line reason for each pick. 7. If no desk fits someone, add them to the queue (add_users_to_draft_queue) on the floor where they would best sit, and report them as waiting. Drafts and publishing 8. For each building with changes, create a new building draft named "New hire desk assignment" plus today's date. Never reuse or edit an existing draft. Seat everyone for that building in one update_draft batch, with the permanent recurrence RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYHOUR=0;BYMINUTE=0;BYSECOND=0. 9. review_draft_changes. If any desk would cancel someone's booking, take that seat out of the draft and pick the next desk for that person. 10. [PUBLISH]: publish the floors with changes with publish_draft and confirm with get_draft_status (check at 10, 20 and 30 seconds), or, if I want to approve first, don't publish and put each draft's link from get_draft_url in the report. Don't retry a publish. Report 11. Finish with a short report in three parts: seated (name, email, department, desk, pod, floor, building, reason), waiting in a queue (name, floor and why), and skipped (name and why). End with any errors and Robin's reason. If nobody needed a desk, say so in one line. If the Robin connector offers start dates, HR employment data or time off, use them: seat people before their start date and skip contractors HR marks as remote.
Details - Desk clear-out report
Find desks that need clearing after someone leaves, using a saved seating snapshot.
Set up a scheduled task named "Desk clear-out report". - Schedule: [RUN TIME], my time. - Connectors for its runs: Robin (Workplace) and Claude Docs, plus Slack if the report goes to Slack. - Notifications: [NOTIFICATIONS] when a run finishes. - First check my scheduled tasks. If another task already reports or releases desks of people who left, show it to me and ask whether to replace it. - Run it once now so the snapshot doc "Robin desk assignment snapshot" exists from today. People removed before today can't be found, because Robin no longer has them. - If the desk action below releases desks, check that I have planning access to the buildings in scope. After creating it, tell me its approval setting. Use this as the task's prompt: Find desks that still have someone's things on them after that person left, and report where each desk is so someone can clear it out. Use the Robin (Workplace) connector, and the Claude Docs connector for the snapshot. Don't ask questions; nobody is watching this run. Unless the desk action below releases desks, only read from Robin. Scope: [BUILDINGS]. Who counts as gone: [WHO]. Also report: [ALSO]. Snapshot 1. Take today's snapshot of every assigned desk in scope. For each building: get_building_overview to find floors with assigned desks, get_building_live_state once, then get_draft_data for each of those floors. Record every desk that has an assignee: building, floor, pod, desk name, desk id, person's name, email and user id. The live-state copy can carry pending edits other people made; if a floor's assigned-desk count there disagrees with find_desks assigneeCount, trust find_desks and note it. 2. Find my Claude doc titled "Robin desk assignment snapshot" and read its table. That is the snapshot from the last run. If the doc doesn't exist yet, this is the first run: create it, save today's snapshot, and only report the people found in step 4. Who left 3. Compare the two snapshots. For every desk whose person is gone from it, look that person up with find_people, userNameFilter set to their email and statuses ACTIVE, ADDED, INVITE_PENDING, INVITE_EXPIRED and DEACTIVATED. If they aren't found, they were removed from Robin: put the desk on the clear-out list with the name and email from the last snapshot, since Robin no longer has them. 4. find_people with statuses DEACTIVATED (and INVITE_EXPIRED if expired invitations count), paging through every result. Anyone in today's snapshot with one of those statuses still holds a desk: put it on the clear-out list. 5. If a person from the last snapshot is now at a different desk, list them as moved, with both desks, so their things can follow them. If they're still active but have no desk now, list the old desk as "check this desk". 6. Flag anyone who left but also has an active account under the same name, and desks whose desk name is the person's name. Desks to release 7. [DESK ACTION]. Removed people's desks are already free in Robin. To release desks still assigned to deactivated or expired accounts: create a new building draft per building named "Desk clear-out report" plus today's date (never reuse an existing draft), set those desks' assignments to an empty list in one update_draft batch keeping each desk's type, run review_draft_changes, then either leave it unpublished with its link from get_draft_url, or publish with notifications off and confirm with get_draft_status. Save and report 8. Replace the table in "Robin desk assignment snapshot" with today's snapshot (one row per desk: building, floor, pod, desk name, desk id, person, email, user id) and put today's date at the top. Only do this after the comparison, so the last snapshot isn't lost. 9. Report in parts (desks to clear, people who moved, desks to check), with totals first. List desks grouped by building, then floor, then pod, so someone can walk them in order. For each desk: desk name, desk id, the person's name and email, why, and whether it was released. End with any flags and errors with Robin's reason, and a link to the snapshot doc. If there's nothing to report, end with one line: "Nothing to clear." If the Robin connector offers user removal history, HR offboarding data, a clear-out status or last check-in dates, use them: find removed people directly instead of from the snapshot, include people leaving in the next 7 days, leave out desks already cleared, and add when each desk was last used.
Details - Auto-book my desk
Book your preferred desk automatically for the days you come in.
Set up a scheduled task named "Auto-book my desk". - Schedule: every [RUN DAY AND TIME], my time. - Connectors for its runs: Robin (Workplace), plus Slack if I asked for a Slack DM below. - Notifications: [NOTIFICATIONS] when a run finishes. Email and phone notifications are task settings; a Slack DM is the last step of the task. - Before creating it, look up my desk with find_desks to get its desk id, floor id and building id, and run check_desk_availability for one upcoming day to confirm it can be booked. Tell me if it can't. - After creating it, tell me its approval setting. Runs only book on their own when the task approves automatically. Use this as the task's prompt, with the ids filled in: Book my desk in Robin for the next [WEEKS AHEAD] weeks. Use the Robin (Workplace) connector. Don't ask questions; nobody is watching this run. Desk: [DESK] (desk id, floor id and building id). Use the building's time zone for every booking. Days: [DAYS AND HOURS]. 1. get_current_user_info for today's date. Plan every office day from tomorrow through [WEEKS AHEAD] weeks out. 2. get_building_hours for the building over that range (at most 31 days per call). Skip closed days. Also skip US public holidays, even when Robin lists the building as open. 3. get_user_desk_reservations for the range. Skip any day where I already have a desk booking anywhere. 4. check_desk_availability for my desk with one window per remaining day, in the building's time zone. For each bookable day, call book_desk with the same desk, window and time zone, and reservationType set to the bookAs value it returned. 5. If my desk can't be booked on a day, book [IF MY DESK IS TAKEN]: use find_desks for the floor and check_desk_availability on those desks, and book the first bookable one. Never book a hot desk ahead of time. If nothing fits, skip the day and say why. 6. Never cancel, move or change a booking that already exists. 7. Finish with a short summary: each day, the desk booked, any backup desk and why, days skipped and why, and any failure with Robin's reason. If I asked for a Slack DM, send that summary to me as a Slack direct message. If the Robin connector offers my work schedule, time off or building closures, skip days I'm out or the building is closed.
Details - Networking events near the office
Find nearby events to meet people in your industry.
Set up a scheduled task named "Networking events near the office". - Schedule: [RUN TIME], my time. - Connectors for its runs: Robin (Workplace), plus Slack if the report goes to Slack. Runs need web search. - Notifications: [NOTIFICATIONS] when a run finishes. - First check my scheduled tasks. If another task already looks for events or books desks around them, show it to me and ask whether to replace it. - If runs book desks, tell me the task's approval setting after creating it; desks are only booked when it approves automatically. Use this as the task's prompt: Find networking events within [RADIUS] of my Robin office over the next [LOOK AHEAD], and tell me which days are worth coming in for. Use the Robin (Workplace) connector and web search. Don't ask questions; nobody is watching this run. Only read from Robin unless the desk setting below books desks. Where and when 1. Call get_current_user_info for my user id, time zone and the current date and time. Work out every date from that, in my time zone. The window is from tomorrow through the next [LOOK AHEAD]. 2. Office: [OFFICE]. Call get_office_locations for its street address and time zone. That address is the center of the radius. Find events 3. Run several targeted searches, not one broad one: "networking events [neighborhood or street] [city] [month year]", "[city] meetup [month year]", "eventbrite networking [city] [month]", "luma [city] events", "[city] chamber of commerce events [month]", plus my topics: [TOPICS]. Open the listing pages for promising results, since snippets often miss the venue or have old dates. 4. Keep events whose main purpose is meeting people professionally: [EVENTS]. Skip large ticketed conferences unless I included them, classes, online-only events, and purely social or nightlife events. For each, keep the name, date, start and end time, venue name and address, and link. Drop anything without a date or a venue address. 5. Judge distance from the addresses; there's no map tool. Within the radius: same street, same or next block, or a walking-distance search that fits. If it's likely close but you can't confirm, keep it and mark it "unconfirmed". Drop anything clearly farther. Never invent events, venues or distances. Check the days 6. Call get_building_hours for the window (31 days at most per call). Leave out days the building is closed, but mention them in one line each. 7. Call get_user_desk_reservations for the window and note days I already have a desk. 8. Desks: [DESKS]. To find one, call find_available_desks on my default floor for the building's open hours and pick one desk, trying other floors if mine is full, then check them all in one check_desk_availability call with each day as its own window and the building's time zone. To book, use book_desk with the bookAs value from check_desk_availability, only for ready days within the radius, only for me. Report 9. Start with one line: how many events you found and how many days are worth coming in. Then one row per day in date order: date, event with its link, venue and distance, time, desk, and status (ready, booked, already have a desk, distance unconfirmed, no desk free, or the booking rule with its reason). Under the table, one line for each event left out that I might care about. 10. If nothing was booked, end by saying I can reply in this run with the days to book. Don't book before I reply. Don't register or RSVP for events; link them so I can sign up. If nothing qualifies, end with one line saying so.
Details - Desk waitlist
Watch for a desk to open up and book it when one becomes available.
Set up a scheduled task named "Desk waitlist". - Schedule: [CHECK HOURS], my time. The task turns itself off after the last watched day. - Connectors for its runs: Robin (Workplace) and Claude Docs, plus Slack if I want a Slack DM. - Notifications: [NOTIFICATIONS], but only for runs where something changed. Runs with nothing new end with "No change." and send nothing. - Before creating it, check that the watched days are really full right now and tell me. If a desk is already free, offer to book it now instead. - If runs book desks, tell me the task's approval setting after creating it. Desks are only booked when it approves automatically. Use this as the task's prompt: Watch for a desk to open up on days that are full, and [ACTION] as soon as one does. Use the Robin (Workplace) connector and the Claude Docs connector. Don't ask questions; nobody is watching this run. Only write to Robin if the action is to book. What I'm watching: [WATCH]. Days: [DAYS]. Time: [TIME]. Each run 1. Call get_current_user_info for my user id, time zone and the current date and time. Ignore any watched day that has already passed. 2. Open my Claude doc "Robin desk waitlist". It lists each watched day and whether it's still being watched, booked, notified or dropped. Skip days that aren't still being watched. If the doc doesn't exist, create it with every day above marked "watching". 3. Call get_user_desk_reservations for the watched days. If I already have a desk on a day, mark that day "has a desk" in the doc and stop watching it. 4. For each day still watched, look for a free desk with find_available_desks (or check_desk_availability for a specific desk) for the time above. Confirm the one you'd take with check_desk_availability, passing the building's time zone, so booking rules and advance limits show up. A desk counts only if it's bookable for me. 5. If the action is to book: book it with book_desk, using the bookAs value from check_desk_availability and the same time zone, for me only, and mark the day "booked" with the desk, floor and time. If the action is to tell me: don't book, and mark the day "notified" so later runs don't tell me again. 6. If a day can't work at all (the building is closed, or a booking rule will never allow it), mark it "dropped" with the reason. What to say 7. If nothing changed this run, end with exactly "No change." and nothing else. 8. If something changed, say only what changed: each desk booked or found (day, desk, floor, time), any day dropped and why, and that I can reply in this run to cancel or book. 9. Stop [STOP]. When no watched day is left, turn this scheduled task off with update_trigger (enabled false) if you can, and say so. If you can't, say "You can turn this task off now."
Details
Portfolio2
- Portfolio right-sizing scorecard
Rank every building by desks and typical daily desk use to spot consolidation candidates.
Using the Robin connector, build an interactive portfolio right-sizing scorecard for every office in my organization. Publish it as an artifact using our design system. Pull the data 1. List every office location. For each one, read the building overview to get active desks by floor and booking type (assigned, hotel, hot). 2. Leave out floors that are not workspace, such as parking, garage, lockers, labs, and test or example floors. List what you left out. 3. For each building, run "average desks used per day" grouped by day for the last 30 completed days. This gives desks booked per day. 4. Run the same metric grouped by day and by checked in. The checked-in rows give desks checked into per day. If a building returns no rows or you have no planning access, keep it in the list and mark it as having no data. Calculate for each building, once for booked desks and once for checked-in desks - Workspace desks: active desks on the floors you kept. - Typical day: the median of the daily values. - Peak day: the highest daily value, after leaving out bulk-booking spikes (any day more than double the median and at least 20 desks above it). List the spike days you left out. - Typical and peak utilization: typical day and peak day divided by workspace desks. - Days booked: days with any desk booking, out of the weekdays in the window. - Check-in rate: total checked-in desk-days divided by total booked desk-days. If a building has bookings but no check-ins at all, treat check-in as not in use there and do not score it on the checked-in measure. - Could release: workspace desks minus (peak day divided by a target peak utilization). Default the target to 85% and never go below zero. - Status from peak utilization: under 40% is a consolidation candidate, 40 to 70% has room to tighten, 70 to 90% is right-sized, 90% or more is running tight. Buildings with fewer than 10 booking days are "not enough data" and are not scored. Build the page - Summary row: total workspace desks, desks used on a typical day, desks used on each building's peak day, the portfolio check-in rate, and desks you could release at the target. - Controls: a toggle to measure use by booked desks or checked-in desks (default to booked) that recalculates everything, a slider for target peak utilization (60 to 95%) that recalculates everything, status filter chips with counts, and a building search. - A stacked bar showing how many desks sit in each status. - A table ranked by desks you could release, with sortable columns: building, status, desks, typical day, peak day, a utilization bar (typical, peak, and a target marker), days booked, check-in rate (highlight anything under 50%), and could release. - Selecting a row expands it to show floors with their desk-type mix, a small daily chart with booked and checked-in lines, the target line, and excluded spike days marked, and one sentence on what the building could give back. - A "How to read this" section that explains each calculation, and a "Data notes" section listing excluded floors, buildings with no desks, and any building whose floor totals do not match its desk count. Rules - Say that booked desks include no-shows, and that a low check-in rate can mean no-shows or desks where check-in is not required, which is common for assigned desks. - Report buildings and floors only. Do not show individual names. - If headcount per building is not available, say so rather than estimating it.
Details - Floor exit and sublease finder
Find floors that could be vacated or sublet without displacing teams that need them.
Using the Robin connector, build an interactive floor exit and sublease finder for every office in my organization. Publish it as an artifact using our design system. Pull the data (last 30 completed days) 1. List every office location. For each one, read the building overview with neighborhoods to get each floor's active desks, desk types (assigned, hotel, hot) and neighborhoods. 2. Leave out floors with no active desks and floors that are not workspace, such as parking, garage, lockers, labs, and test or example floors. List what you left out. Skip buildings with only one workspace floor. 3. For each building, run "average desks used per day" grouped by floor and day. This gives desks booked per floor per day. 4. Run the same metric grouped by floor, day and checked in. Keep the checked-in rows as desks checked into per floor per day. 5. Run the same metric grouped by floor and department to see which teams use each floor. 6. Skip scoring buildings with fewer than 10 booking days. Calculate for each building, once for booked desks and once for checked-in desks - Building total per day: the sum across floors. - Spike days: any day where the building total is more than double its median and at least 20 desks above it. Leave these days out of every peak and list them. - Floor typical day: the median of that floor's daily values. Floor peak day: its highest day, without spike days. - Building peak day: the highest building total, without spike days. - Floors you could exit: go one floor at a time, starting with the least-used floor (ties go to the larger floor). Remove the floor only if the building peak day still fits in the remaining floors' desks at or under a maximum peak utilization. Default that maximum to 85%. Always keep at least one floor. - Teams on each floor: split the floor's typical day by each department's share of desk use on that floor, so team numbers add up to the floor's typical day. - Move plan: move each team on an exit floor as one group. Room on a kept floor is its desks times the maximum, minus that floor's peak day, reduced as teams land. Send a team to a kept floor where it already sits if that floor has room, otherwise to the kept floor with the most room. - Sublease fit: if half or more of a floor's desks are assigned, flag "reseat assigned desks first". Otherwise call it a whole floor, and name any neighborhoods that would be retired. Build the page - Summary row: floors you could exit, desks freed, desks to relocate on a typical day, assigned desks to reseat, and buildings not scored. - Controls: a toggle for booked or checked-in desks (default booked), a slider for maximum peak utilization after the move (60 to 95%), and a checkbox to keep floors where most desks are assigned. Each control recalculates everything. - A table of every floor you could exit, sorted by desks freed: building and floor, desks, typical day, peak day, teams on the floor, assigned desks, and sublease fit. Selecting a row opens that building below. - A building view with a building picker: - A stack of floors, top floor first, with bars sized by desks that show typical and peak day, and the exit floors hatched. - A check showing the building peak day against the desks you keep, with the maximum marked. - Next to it, an "After the move" stack with the same floor order and scale. Show exit floors as vacated with desks freed and where their teams go. For each kept floor, draw one bar with the people already there on the peak day in gray, then one colored segment per incoming team, a marker for the maximum, and the resulting peak utilization. List the incoming teams under each bar with a color key, the desks they bring, and the floor they come from. - Below both, the move plan grouped by destination floor: one card per kept floor that receives people, listing each incoming team, where it comes from, how many of its colleagues already sit there, and desks a day. Then list the assigned desks to reseat and the neighborhoods to retire. - A "How to read this" section that explains each calculation, and a "Data notes" section for excluded floors and skipped buildings. Rules - Say that booked desks include no-shows, and that checked-in desks undercount where check-in is not required, which is common for assigned desks. - Report floors and departments only. Do not show individual names. - Present destinations as a starting point for a seating draft in Robin, not a final plan.
Details
Stack and space planning4
- Current-state stack plan
Show which departments use which floors today, question that setup, and shape a new floor plan by moving teams.
Using the Robin connector, build an interactive stack plan for [building name] that shows where each team is today, flags what looks off, and lets me move teams between floors. Publish it as an artifact using our design system. Do not change anything in Robin. Pull the data (last 30 completed days) 1. Read the building's current plan through its live state: each floor's desks by type (assigned, hotel, hot), neighborhoods and any seat assignments. Also read the building overview so you can compare the plan with the live floor plan, and tell me if they differ (seats, neighborhoods, desk types). 2. Run "average desks used per day" grouped by department and day for the building, and grouped by floor and department. 3. Get headcount per department for the organization. 4. Find bulk-booking days: days where the building's desk bookings jump to more than double the median. Leave them out of team sizes and list them. Calculate - Typical day and peak day for each department: the median and the highest daily value on normal days. - Teams seen only on bulk-booking days: size them from their bulk-day count and mark them "confirm size". - Desks needed: typical or peak day plus a buffer (default peak day plus 10%). Let me override any team's number. - Today's layout: spread each team's desks needed across the floors it books, in proportion to its bookings on each floor. If seat assignments exist, use those instead and say so. Build the page - Header with two buttons: "Copy stack plan prompt" and "Copy draft prompt". Nothing on the page writes to Robin. - Summary row: desks in the building, desks teams need, overflow past floor capacity, teams split across floors, and desks moved from today. - Controls: Today or Your plan, size by typical or peak day, a buffer slider (0 to 40%), and buttons for "Suggest a consolidated plan", Undo and "Start from today". - Stack chart: one row per floor, top floor first. Each bar has one colored segment per team with its desk count, a line at the floor's desk count, hatched red for overflow past it, a thin band showing assigned, hotel and hot desks, and the floor's neighborhoods listed underneath. Drag a team to another floor to move all of it. Select a team to move part of it to a chosen floor. Mark segments that differ from today. Show a toast after each move. - Teams table: team, people in the org, typical day, peak day, editable desks needed, floors today, floors in the plan, and a check (one floor, split, or confirm size). - "What looks off": teams spread over three or more floors, teams only seen on bulk days, desks no team needs, floors that are mostly hotel and hot desks, neighborhoods that don't match a team, and differences between the plan and the live floor plan. Give each a one-click fix where there is one. - "Suggest a consolidated plan": biggest teams first, each placed whole on one floor that fits, preferring a floor it already uses. Split only teams that fit nowhere. - Stack plan prompt: create a stack plan with two options, "Today, from bookings" and "Proposed" (desk totals per team), and an allocation with my floor split. Report shortfalls. No draft, no desk changes. - Draft prompt: create a NEW building draft with one neighborhood per team per floor, sized to my plan, preferring assigned desks. Remove neighborhoods that no longer match a team, listing them first. Don't seat anyone. Review and give me the link. Do not publish. Turn this button off until the plan differs from today and has no overflow. Rules - Say that bookings include no-shows, and that headcount is org-wide because Robin does not store a home building per person. - Report teams and floors only. Do not list individual people.
Details - Split team detector
Find departments spread across floors in every building and propose where to bring each one together.
Using the Robin connector, build an interactive split team detector for every office in my organization. Publish it as an artifact using our design system. Do not change anything in Robin. Pull the data (last 30 completed days) 1. List every office location and read each building overview for floors and active desks. Leave out floors with no desks and non-workspace floors (parking, garage, lockers, labs, test or example). Skip buildings with one workspace floor. 2. For each building, run "average desks used per day" grouped by floor and day, and grouped by floor and department. Calculate per building - Spike days: building total more than double its median and at least 20 desks above it. Leave them out and list them. - Each floor's typical day (median) and peak day. - Team desks per floor: split the floor's typical day by each department's share of bookings on that floor. A team's total is the sum over floors. - Split team: a team at or above a minimum size (default 5 desks a day) that uses at least a floor threshold (default 2 desks) on two or more floors. Main floor is where it books most; away desks are the rest. - Proposed floor: going through split teams biggest first, pick the first floor the team already uses that has room for the rest of it. Room is the floor's desks times a maximum peak utilization (default 85%) minus its peak day, updated as teams move in and out. If no floor fits, propose the main floor and show how many desks it is short. Build the page - Summary row: split teams out of teams checked, desks away from the main floor, buildings with a split team, moves that fit, and teams left split on purpose. - Controls: smallest team to check, floor threshold, max peak utilization, "treat spelling variants as one team" (on by default, e.g. Sales and sales), and "include people with no department" (off by default). Every control recalculates. - A table of split teams, most spread out first: team and building, desks a day, a bar of its spread across floors with the main floor highlighted, desks away from the main floor, a dropdown to pick the floor to bring it together on (or "Leave split"), and a fits or short-by-N tag. Changing a dropdown rechecks the whole building. - A building view with a picker: "Today" and "After bringing teams together" stacks side by side, one bar per floor sized by desks with a segment per team (top 8 teams colored, the rest gray), the selected team outlined, the limit marked, and each floor's peak utilization. - A "Copy prompt for this building" button. The prompt lists each team to bring together with its current floors and target floor, then asks Claude to check against current seat assignments and neighborhoods, create a stack plan and allocation, and build a NEW unpublished draft with one neighborhood per team on its target floor (moving assigned people if there are any). Review and give me the link. Do not publish. - A "How this works" section that explains each calculation. Rules - Say this works from bookings (including no-shows), so it finds teams that sit apart in practice, and that the prompt checks seat assignments before drafting. - Report teams and floors only. Do not list individual people.
Details - Manager seating request
A shared page where managers pick any people in the company, place them at specific desks on a floor and set hotel desks, and admins review every resulting move and apply it in Robin with one prompt.
Using the Robin connector, build a manager seating request page for [BUILDING] and publish it as an artifact using our design system. Only read from Robin. Nothing on the page writes to Robin. Data to pull (read-only) 1. get_office_locations for the building id, then get_building_overview with includeNeighborhoods for every floor, its desks by type and its neighborhoods with desk ids. 2. get_building_live_state once, then get_draft_data for each floor: every desk's id, pod, name, booking type, neighborhood and assignees with their weekdays. Use find_desks with levelId only as a fallback. 3. find_people for everyone who sits in the building, plus active and added people with no desk, so managers can seat new hires. Keep name, department and title. Look up any assignee with no department by name. 4. get_neighborhood_colors for the colors Robin draws. Snapshot all of it into the page and show the snapshot date. The page - Give the page the db and user capabilities, plus the mcp capability for Robin (Workplace) with only find_people and search_entities, for the people search. Requests live in a shared "requests" collection: floor, the people on the request, placements (desk id and user id), hotel desk ids, the manager's note, status (draft, with admin, sent back, applied), author id, dates and an admin note. Store user ids only and show names from the user capability. - A list of requests on the left and a New request button. - For a request: pick a floor and show every neighborhood on it, in Robin's order and colors, with desks that aren't in a neighborhood last. Each neighborhood shows its desk, seated and open counts, and a row of chips at the top jumps to any neighborhood. Desks are small 28px tiles grouped by pod, with initials colored by department, open desks outlined, hotel and hot desks marked, and the manager's changes ringed. Hovering a desk shows a card with the desk, neighborhood, pod and type, each person's name, department, title and days, and what the request changes there (who moves in, from where, and where today's occupant goes). Managers can drag anyone already seated to another desk too, and the page scrolls while they drag near the edge. - People to seat, in a sticky panel beside the floor: a typeahead that searches every employee in Robin as the manager types (find_people with the first word as userNameFilter, plus search_entities for USER, merged with the people in the snapshot). Arrow keys and Enter pick a name. Each person shows their department, title and where they sit today. Keep the name, department and title of anyone added from the live search on the request, so admins see them too. Drag a person onto a desk, or tap the person and then the desk. One desk per person. The desk becomes an assigned desk for them Monday to Friday, and their old desk opens up. - Set hotel desks: tap desks to make them hotel desks, tap again to undo. - Move displaced people automatically and give the manager no controls for it, only a one-line count. Anyone sitting at a desk the manager takes or makes a hotel desk moves to an open assigned desk outside the neighborhoods being changed: same floor first, then the desk the new person left, then the pod with the most people from their department. They keep their weekdays. If no open desk is left, list them as without a desk. - Send to admin locks the request. The manager can take it back to edit. - A review section that everyone can see once a request is sent: counts (people placed, people moved to make room, desk type changes, people without a desk), and a table of every person who moves with from, to and why. - For people who can edit the page (admins): a note to the manager, Copy draft prompt, Copy publish prompt, Mark applied and Send back. The prompts create a new building draft, first check every listed desk against its "was" state and stop if anything changed, apply the desk changes with update_draft, run review_draft_changes and show bookings that would be cancelled. The publish prompt asks whether to notify the people affected, then publishes after I confirm. List only desks whose state changes, with the new state and what was there. When it's published, tell me to share it from the Share menu: managers need at least Contributor access to save requests, and admins need Editor access to see the admin actions. Share it only with managers and workplace admins, since it shows where everyone sits.
Details - Comprehensive stack plan
See every assigned desk in a building and who sits there, size each team's sharing ratio from real desk use, convert teams to hotel desks, plan moves, and hand Robin a draft with exactly those changes.
Using the Robin connector, build a comprehensive stack plan for [BUILDING] and publish it as an artifact using our design system. Rent is $[RENT] per square foot per year. Only read from Robin. The page starts identical to Robin today: don't move anyone, change desk types, create neighborhoods or apply seating rules unless I ask. Desk types change only when I convert a team to hotel desks on the page. Pull the data 1. get_office_locations, then get_building_overview with includeNeighborhoods true: floors, desk counts by type, neighborhoods with their color slots and desk ids. Skip floors with no desks. get_neighborhood_colors for the hex colors. 2. Every desk on each floor with find_desks (levelId): id, pod, desk name, booking type and assigneeCount. 3. Each desk's assignees and weekdays: get_building_live_state once, then get_draft_data per floor. The live-state copy can carry other people's pending edits, so compare each desk's assignees with find_desks assigneeCount. Where they differ, take the live assignees from review_draft_changes (detailed, the "previous" side) or check_desk_availability, and tell me which floors differed. 4. People: get_departments, then find_people per department (exact names, statuses ACTIVE and ADDED, every page) for name, department, title and manager. Look up any assignee still missing by name. 5. Desk use by department in this building: avg_desks_used_per_day for the last 30 completed days, grouped by day, assignee department and checked in. Leave out weekends and bulk-booking days (more than double the median and at least 20 desks above it) and list them. For each department keep the typical day (median) and peak day, booked and checked in. 6. Snapshot all of it into the page and show the snapshot date. Tell me about anything odd: assigned desks with no one on them, empty neighborhoods, overview counts that don't match find_desks, odd department names. Build the page - Header with "Copy draft prompt" and "Copy publish prompt". Nothing on the page writes to Robin. - Control bar: Robin today (read-only) or Plan, Organize by Department, Manager or Neighborhood, Undo and Reset moves. - Five tiles: floors in use, people with assigned desks (and the change from today), assigned desks, spare assigned desks (or people without a desk, in warning color), rent saved or added per year. - Stack chart, one row per floor with "seated/assigned" on the left: a segment per group sized by desks, then open assigned desks, planned hire seats, hot and hotel desks, and red hatched overflow for people without a desk. Gridlines, a desk axis and a legend. Drag a group to another floor to move it, or onto another floor's group to swap. Click a group to move part of it. Mark segments that differ from Robin today. Toast after each move. - Seat view, one row per floor: plain 28px squares in one wrapped run, grouped together, with initials on the group color. Split a desk with two weekday assignees diagonally and show both initials. Outline open assigned desks, gray hot and hotel desks. Hover shows name, department, title, manager, desk and days. Drag a desk to an open desk, onto someone to swap, or onto a floor in the chart; on phones, tap a desk and then tap where it goes. A shared desk moves as one. - When moving people to a floor, pair weekday-only people onto desks with free days first, then use open desks next to their group. Anyone who doesn't fit stays as a chip under that floor until I give them a desk. - Sharing ratio, one row per department: people with assigned desks in the plan, typical and peak day, peak divided by people, an editable desks-per-person ratio, hotel desks needed, desks freed, and "Convert to hotel" (or Undo once converted). Measure use by desks booked or desks checked in. Suggest each ratio as peak day plus a [BUFFER] buffer divided by people, rounded up to 0.05, no lower than [LOWEST RATIO] and no higher than 1; both settings are editable. Tag teams whose peak is under 0.15 desks per person as "Low use". - Converting a team moves everyone in it off their assigned desk. Hotel desks needed = people times the ratio, rounded up. Take them first from the desks the team leaves, then from open assigned desks on the floors where it sits most, then from open desks on other floors; if there aren't enough, say how many are short and don't convert. Desks the team leaves beyond that stay assigned and open. On a desk shared with someone from another team, that person keeps it. Show the hotel desks striped in the team's color in the chart and seat view, refuse moves onto them, and don't let me remove a floor that holds them. - Neighborhood table (Neighborhood view): Robin's neighborhoods per floor with desks and seated counts. - Forecast: headcount per group with Today, minus, typed change, plus and Planned, a "change everyone by %" control, and planned hires shown as + seats on open desks near their group. Floors table with assigned desks, people, editable square feet (175 per assigned desk until typed), Remove or Add back, and Add a floor with N desks. Removing a floor reseats its people on other floors, preferring floors where their group sits. A Robin today vs plan comparison. - Footer with the snapshot date, desk totals by type and how moves and prompts work. Prompts - Turn both off in Robin today, while a headcount change or added floor is set, while anyone has no desk, and until something differs from Robin. - Each opens a panel with the text, copies it, and has Copy prompt and Close. - Text: create a NEW building draft named "[BUILDING] · Plan · [date]" (never reuse one), apply the changes with update_draft in batches of about 100 chaining versions, give each listed desk isReservable true and reservationTypes ["assigned","shared"], except converted hotel desks, which get ["hoteled"] and no assignments, weekday recurrences as RRULEs (Mon-Fri, every day, or single days), "clear" means no assignments, desks not listed keep theirs. Then review_draft_changes: changes per floor, desk type changes and every booking publishing would cancel, plus the draft link. Draft prompt: do not publish. Publish prompt: after I confirm, publish all floors with notifications off and check get_draft_status until it says whether it went live. - List only desks whose people or type differ from the snapshot, one per line: desk id [floor, pod desk]: user id name (days) + second person if shared, "clear", or "hotel (team)". - When a team is converted, add a HOTEL NEIGHBORHOODS list (team hotel desks, floor: desk ids) and ask Claude to put those desks in a neighborhood with that name on that floor in the same draft. If one with that name exists, replace its desks, reading get_draft_data first and keeping its description.
Details
Hybrid policy2
- Hybrid policy recommender
Recommend a realistic hybrid policy from the culture you want and how people use the office today, check it fits each building's desks, and draft the policy.
Using the Robin connector, build a hybrid policy recommender for [BUILDINGS] and publish it as an artifact using our design system. Only read from Robin. The page asks about the culture we want and recommends a policy that is realistic for how people use the office today. Pull the data ([WINDOW], weekdays only) 1. For each building: workspace desks by type from the building overview, leaving out parking, lockers, labs and test floors. 2. Days in office per person: desk check-in days grouped by department and person, divided by the weeks in the window. Keep only a histogram per department and building (people at 0, 1, 2, 3, 4 and 5 days); never store or show names. Count people who booked but never checked in as 0. If a building has no check-ins at all, use booked days instead and say so. 3. Weekday pattern: desks used per day grouped by department and weekday, leaving out bulk-booking days (more than double the median and at least 20 desks above it). 4. Tell me about anything odd, such as the same people booking several desks a day or booking in many buildings at once. Questions on the page (each answer updates everything) 1. What the office is for, up to three: working together, mentoring and onboarding, culture and belonging, client meetings, focus work, time with leadership. 2. How structured: let the answers decide (default), recommended days for everyone, recommended team days, a minimum with free choice, or guidance only. 3. How many days you'd like in the end (1 to 5). 4. Days you'd like people together (optional). 5. How you'll hold people to it: a guideline, tracked by team, or part of performance. 6. Exceptions: remote-hired roles, caregivers, long commutes, field and client roles. 7. Fridays: optional, like any day, or light with no recommended days. 8. If a building gets too full: stagger teams, free up desks, or accept tight days. How to recommend - What the office is for drives the policy, not just the wording. When the structure is left to the answers: working together and mentoring point to recommended team days, time with leadership to recommended days for everyone, culture to both, and focus work or client meetings to a minimum people choose. Ties go to recommended team days. - Recommended versus open days: focus work caps recommended days at two, client meetings turns one recommended day into a day people choose, and working together or mentoring keeps at least two recommended days. - Mentoring encourages new hires and their managers to come in on the team's recommended days; time with leadership puts leaders in on the shared days. - Policy days now: your goal, capped at today's average plus one day, rounded down. If that's below the goal, plan one more day each quarter. - The policy is a number of days a week. Days for everyone or for each team are recommendations, not rules: Robin's hybrid policy tracks how many days people check in, not which days. Say so on the page and in the draft. - Recommended days: the days you picked, otherwise the days people already choose most. For recommended team days, when working together, culture or leadership is chosen, give every team a shared day the building can hold (preferred days first, then the quietest days). If no single day fits everyone, pair teams into two groups with their own shared day and say why. Spread the other recommended team days so each building's busiest day fits its desks. - Expect 65%, 85% or 95% of people to follow it (guideline, tracked, performance), 50% for guidance only, with a slider to change it. Exempt people and people who don't follow it keep today's pattern. - Capacity: expected people per weekday per building against desks. Over 85% is tight, over 100% doesn't fit. Say what to do based on the overflow answer. Build the page - Four tiles: days in office today, recommended days a week now, share who already meet it, and the busiest building day against its desks. - The questions on the left; on the right the recommendation with the reasons behind it, today's spread of days per person against the policy, the capacity check by building and weekday, recommended team days per building, a rollout plan (agree it with leadership and HR, pilot six weeks in the building with the most room, turn it on in Robin, review, step up), and the policy draft. - Policy draft sections: why we come together, what we expect (a number of days, with recommended days), how it will change, Fridays, new team members, exceptions, booking and checking in, how we'll measure it, and review. "Copy doc prompt" asks Claude to make it a Claude doc for HR review; "Copy policy text" copies the text. - Robin setup steps: Manage, Hybrid Work Policies, Default Policy; set a minimum number of days per week; put the recommended days in the message; turn it on; export the monthly check-in report. Say that Robin holds one policy for the whole organization and tracks the number of days, so recommended days go in the message and team calendars. Rules - Report teams, never individuals. Note that the approved policy and exceptions belong in the HR system. - Say which basis days per week come from (check-ins or bookings) and that bookings include no-shows.
Details - Hybrid policy adherence
Show who is meeting the hybrid policy, person by person and by team and building, whether it's moving since the policy started, and whether recommended days are being used.
Using the Robin connector, build a hybrid policy adherence report for every building with desk bookings and publish it as an artifact using our design system. Only read from Robin. Our policy is at least [POLICY DAYS] days a week, starting [POLICY START], with [RECOMMENDED DAYS] as recommended days. The page lists each person, so keep it private and share it only with the people who handle attendance (HR and, if you choose, managers for their own teams). Check local rules on monitoring attendance before sharing it, especially in the EU. Pull the data (the last [WEEKS] completed weeks) 1. For each building, desk check-in days grouped by department, person and week (desk_checkin_days_count with reservation__assignee_department, reservation__assignee_id and metric_time__week; split by department if a result is truncated). Keep one row per person: name, department, building (where they checked in most) and days checked in each week. Look up names with find_people. People who booked in the building during the window but never checked in count as 0 every week. 2. Desks used per day grouped by department and weekday, for the share of office days on recommended days. 3. Workspace desks per building from the building overview. 4. Holidays in the window: [HOLIDAYS]. Calculate - A person meets the policy in a week if they checked in on at least the policy days; in a holiday week, the bar drops by the number of holidays (a setting can turn this off). - Share meeting it and average days a week, per week and for the chosen period, overall and per team or building. Compare with the weeks before the policy started, in percentage points. - Team status against the goal: on track at or above it, getting there within 20 points, behind beyond that. - Person status over the period: meeting it if they met the policy in at least 75% of weeks, some weeks at 50 to 75%, not meeting it below that, and no check-ins if they had none. Build the page - Settings: policy days (1 to 5), period (last 4 weeks, since the policy started, all weeks), group by team or building, goal (60 to 90% meeting it), whether people with no check-ins count, and whether holiday weeks lower the bar. - Five tiles: share meeting the policy, days a week now and before, change since the policy, teams under goal, and the share with no check-ins. - A weekly line chart of the share meeting the policy, with average days a week on a second axis, the goal line, the policy start and holiday weeks marked. - A table per team or building: people, days a week, share meeting it, change since the policy, a weekly sparkline, a bar of people by days, and status. - People: a table of everyone with team, building, days a week, weeks met out of the period, a square per week (met, came in but short, not in) and status. Search by name, filter by team, building and status, sort by name, days or status, show 25 at a time, and "Copy this list" to paste the filtered list into a spreadsheet. - Which days people choose: per building, attendance by weekday with the recommended days highlighted (editable) and the share of office days on them. Say that recommended days are suggestions and Robin counts how many days, not which. - Before and after: people by days a week before the policy and in the period. - A leadership summary in plain language with a copy button. It names teams, not people. Rules - Say that check-ins come from badge swipes, Wi-Fi, desk QR codes or remote check-in, the same signal as Robin's hybrid policy banner, and that approved exceptions aren't in Robin. - Say that approved exceptions need checking before anyone follows up with a person, and that follow-up decisions belong in the HR system.
Details
Employee experience4
- Sit with my team
Book a desk on a chosen day next to where your manager or teammates are already booked, from a live page that reads and books through Robin.
Build me a live "Sit with my team" page as an artifact using our design system. The page should call the Robin Workplace connector itself, with my permission, so it stays current and can book desks for me. Give it the mcp capability for my Robin connector, using the connector's exact display name from my connector list (for example "Robin (Workplace)"), with only these tools: get_current_user_info, find_people, get_user_desk_reservations, find_available_desks, find_desks, check_desk_availability, book_desk. What the page does 1. On load, get my Robin profile and today's date from get_current_user_info. Use that date for "this week", never an assumed one. 2. Work out my team with find_people. Offer three choices: my manager's team (my manager plus everyone who reports to them), my own reports, or people I pick by searching names. Cap the list at 20 people. 3. Show a week grid for this week or next week (Monday to Friday): one row per person with me first, one column per day, and in each cell the building and floor they are booked on (from get_user_desk_reservations), colored by floor. Column headers show how many teammates are in that day. Selecting a column picks the day. 4. For the chosen day, list the floors my teammates are on, most teammates first, with who is there and at which desk. 5. "Find desks near them" on a floor calls find_available_desks for 9:00 to 5:00 in that building's time zone, and find_desks once per floor to learn which pod each teammate's desk is in. Group open desks by pod, with the pods where my teammates sit first and highlighted. 6. Picking a desk shows a confirm row. "Book desk" runs check_desk_availability first and books only if it says the desk is bookable, using its bookAs value as the reservation type in book_desk. If it is not bookable, show the reason Robin gives. After a booking, refresh my row in the grid. Rules - Never book without my click on "Book desk", and never retry a booking automatically. If a booking call fails in a way that leaves the outcome unclear, tell me to check my bookings before trying again. - Handle connector problems with specific messages: reconnect Robin, add the connector, allow it for this page, or try again later. - When the connector isn't available (for example in a preview), show a clearly labeled example team with made-up names so the page still makes sense, and disable real booking. - Show only what Robin already shows people about who's in. Do not save anyone's bookings into the page.
Details - Office travel planner
Pick the best days to go into the office from where your team sits, free desks near them and the weather, and decide whether to drive or take transit to arrive on time.
Plan my office week. I live at [HOME ADDRESS], I want to go into the [OFFICE] office, and I need to arrive by [ARRIVAL TIME]. Using Robin, find my team, see which days they're in and where they sit, and suggest which days I should come in and where I should sit. Then work out whether I should drive or take transit, and from which station, using traffic and transit information for those days, and add the weather forecast. Build an artifact using our design system that summarizes all of this in one view. Work these out yourself, don't ask me - My team: get my Robin profile with get_current_user_info, then look me up with find_people to get my department and manager. My team is everyone in my department. If I have no department, use everyone who reports to my manager. If neither is set, tell me and ask who to include. - The destination: the [OFFICE] building's address and time zone from get_office_locations. - The station and line: list the commuter rail or subway stations within a reasonable drive of [HOME ADDRESS] that serve the destination, get each one's weekday timetable, and pick the one that lets me leave home latest and still arrive by [ARRIVAL TIME], counting the drive to the station, parking and the trip from the last stop to the building. How to do it 1. Read each teammate's desk bookings for the next two weeks. If nobody on my team books at [OFFICE], say so plainly and show where they do book instead. 2. For the floor where most of the team sits, check open desks for each weekday (8am to 5pm in the building's time zone). If that floor is full, check the next closest floor, and prefer a pod named for the team. 3. Get the weather forecast at the building for each weekday: high, low and chance of rain. 4. Estimate the drive from [HOME ADDRESS] to the building at that time of day: free-flow time, a weekday rush-hour factor, extra time on rainy days, less on holidays, and time to park. Show it as a range, cite where the traffic numbers come from, and say it is an estimate. Build the page - A strip at the top with my details, marking which ones I entered and which you worked out (team, destination, best station). - Controls for arrival time (30 minutes earlier, my time, 30 minutes later) and how many days to come in (2 or 3). - One card per weekday: a verdict (best day, go in, or work from home), weather with an icon, free desks near the team, the recommended way to travel with a leave-home time, and one short reason. - A "Which station" table comparing the stations near my home: drive time, parking, the latest train that works and when to leave home, with the best one marked. Re-check it when I change the arrival time. - A chart of when to leave home each day, with a bar for the drive range and a bar for station, train and walk, and a line at my arrival time. - Where the team sits (building, floor, pods, people), and where I should sit each day. Show each day's free desks as buttons I can click to book. - A short "How this was worked out" section with sources and assumptions, including holidays. Rules - Let me book desks inline. Give the artifact live access to the Robin connector (the mcp capability, using the connector's exact display name, for example "Robin (Workplace)") with find_available_desks, check_desk_availability and book_desk. - When the page opens, refresh each day's free desks from Robin so the list is current. - Booking opens in an overlay on top of the page, from the "Book a desk" button on each day card or from any desk in the seating table, so I never have to scroll. It shows the day, hours and every free desk to pick from. On confirm, run check_desk_availability first and book with book_desk using the bookAs type it returns. If the desk can't be booked, show the reason Robin gives. - Never book anything without my click. If the connector isn't available, show the plan read-only and say how to turn booking on. - Say clearly that drive times are estimates, not live traffic.
Details - Team onsite planner
Plan a team onsite in one shared page: pick the days, collect replies, see where everyone sits, book desks for anyone who needs one, vote on activities and food, and export a summary for approval.
Build a shared team onsite planner from Robin, using our design system. Work out the team and seating from Robin yourself; don't ask me for them. What to pull - The team: get_current_user_info for me, then find_people with managerIds set to my id. If nobody reports to me, use my manager's team: their direct reports plus the manager. If Robin has neither, show a search to pick the team's manager. - Seating: for each person, get_user_desk_reservations on the onsite days to see their desk, floor and building. Use find_desks on the team's main floor to get each desk's pod by desk id. Work out the pod where most of the team sits. - Room for others: find_available_desks on the team's floor first, then the building's other floors (get_building_overview), and pick the pod with the most free desks together. - Hours: get_building_hours for the onsite days. Flag any day the building is closed. - Days: pick them with an in-page week picker (Monday to Friday buttons with week arrows), not a native date input. Build the page - A title I can edit, then a one-line strip: dates, office, how many are going, how many invited, and an "Export summary for approval" button. - When and where: the onsite days (add and remove), building hours for each, what it's for, and a budget per person per day with a running total for the people going. - Seating: the team's pod as a row of desks with initials, colored by reply (going, maybe, no reply). Call out anyone who sits away from the team. Show the nearest free desks (the team's floor first, then the closest floor by number) for guests or anyone without a desk. Make the map clickable: a person's seat opens their reply and a "book a different desk" option, and a free desk asks who it's for, then books it. - Who's coming: everyone on the team with Going, Maybe and Can't buttons, filter chips by reply, and their desk. The organizer can add guests. - Activities and food: start with one example idea that can be removed, and a clear "Add your first ideas" box at the top (activity or food, then the idea). Show ideas in two columns. Anyone can add and vote; people can remove their own ideas, and the organizer can remove any and mark the ones they're going with. - A short "things to check" box: days the building is closed, people sitting apart, who hasn't replied, and a reminder to book meeting rooms in Robin, since the connector can't book rooms. - Export: a plain-text summary for my approver with dates, place, headcount by reply, budget, purpose, picked ideas, popular ideas, seating, desks booked, replies by name and what's still to do. Offer download as .md and copy. Sharing and booking - Save replies, ideas, votes, guests and bookings with the db capability so everyone who opens the page sees the same plan. Use the user capability so each person votes once and only the organizer edits the plan and picks ideas. Each person sets their own reply; the organizer can set anyone's. Match the viewer to the roster by their Robin id, or by their name (user capability with the profile scope) if they haven't connected Robin, so anyone the page is shared with can reply and vote. - Give the page live access to the Robin connector with the mcp capability, using the connector's exact display name (for example "Robin (Workplace)"), and these tools: get_current_user_info, find_people, get_user_desk_reservations, find_desks, get_building_overview, find_available_desks, get_building_hours, check_desk_availability and book_desk. - Booking opens in an overlay. Check each onsite day with check_desk_availability for that person, then book_desk with the bookAs type it returns, using forUser for anyone other than me. Say that booking for others needs delegate permission in Robin. For a guest, find them in Robin first; for someone outside the company, point to Robin visitors instead. - Never book anything without a click. If the connector or database isn't available, show the plan read-only.
Details - Booking calendar
See your upcoming office days by month, week or day, reserve the days your booking pattern says you'll be in, and see who else is coming.
Build me a calendar of my upcoming office days from Robin, using our design system. Work everything out from my Robin data; don't ask me for it. What to pull - Me: get_current_user_info for my user id, email, default building and today's date. Use find_people with my email to get my department. - My bookings: get_user_desk_reservations from nine weeks ago to nine weeks ahead. - My pattern: a weekday counts if I booked it in at least half the weeks I came in. My usual office, floor, desk and hours are the ones I book most on those days. - The office: get_building_overview for my usual office (floors, desk counts by type, neighborhoods) and get_building_hours for the next eight weeks. Look up public holidays for those weeks too. - Suggested days: every pattern day I haven't booked, skipping days the building is closed and public holidays. Use check_desk_availability to see whether my usual desk is free on each one. - Who's in: for the day I'm looking at, list every desk on each floor with find_desks, then run check_desk_availability on them during building hours and read the reservation names. My team is everyone in my department. Build the page - The calendar is the main focus. Above it, keep only a one-line strip with my pattern, usual office and desk, how far ahead I'm booked and how many days are suggested, plus a "Reserve all suggested" button. - A calendar with Day, Week and Month views. Month is the default. - Booked days should stand out at a glance: solid color with the desk and time. - Suggested days get a dashed outline and a Reserve button. Closed days are shaded. - Week view shows each day on a 7am to 7pm timeline. - Clicking a day opens Day view with my reservations for that day. If I have none, show a "Book a desk" button. - In Day view, add a small, low-key link to book a desk for someone else. - Right below the calendar, a "things to check" box for anything that looks off. For example: bookings I never checked in to, a booking at a different office than usual, a holiday when Robin says the building is open, no department on my profile,. - Then office information written for an employee, not an admin: address, description (only if one is set), time zone, hours for the week and where I usually sit. Leave out floor counts, desk types and setup details. - Below that, who else is in on the selected day, kept light: a count, my team and the people in my pod as photos with names, then everyone else as a row of small photos with "See everyone" to expand into a searchable list. Use profile photos from search_entities (avatarUrl) and fall back to initials when a photo won't load. No desk numbers, pods lists or admin details. Booking - Book inline. Give the artifact live access to the Robin connector with the mcp capability, using the connector's exact display name (for example "Robin (Workplace)"), and these tools: get_current_user_info, get_user_desk_reservations, get_building_overview, get_building_hours, find_desks, find_available_desks, check_desk_availability, book_desk, find_people and search_entities. - When the page opens, refresh everything from Robin so it's current. - Every booking opens in an overlay with a confirm step. Run check_desk_availability first, then book_desk with the bookAs type it returns. If Robin says no, show its reason. - "Reserve all" lists every suggested day in the overlay. If my usual desk is taken on a day, pick the closest free desk, same pod first. Book each day and show the result for each one. - To book for someone else: search people with find_people, check availability for that person's user id, then book with forUser set to their email. Say that this needs delegate permission in Robin. - Never book anything without my click. If the connector isn't available, show the calendar read-only and say how to turn booking on.
Details
Front desk and ops2
- Live office signage
Put today's desk bookings on a lobby or floor screen, grouped by pod, refreshing every few minutes with new bookings highlighted, and let people book a free desk right from the screen.
Build a full-screen office signage board from Robin for a lobby or floor screen, using our design system. It should look good on a 1920x1080 TV and still work on a laptop. Start with my default building and its first floor with desks; don't ask me which. What to pull, every refresh - Today's hours with get_building_hours. If the building is closed or past closing, say so on the screen. - Every desk on the floor with find_desks (desk name, pod), once per floor. - Today's bookings with check_desk_availability on all desks, in chunks of 100, from now until closing in the building's time zone. Read each desk's reservation (name, start time) and whether it's bookable. Count hot desks with no booking as free for walk-ups. - Building and floor choices from get_office_locations and get_location_levels. Skip floors with no desks. The screen - Header: building and floor, a large clock and date in the building's time zone, and a status line (live and when it last updated, example data, or the error). - Left column: desks booked today out of total with a bar, free to book now, how many are arriving later today, a "Just booked" feed, and an "Arriving later" list with times. - Main area: one tile per pod, busiest first. Each tile shows its free count and booked out of total, a row of small squares for its desks (booked, free, or assigned and not bookable), and the people booked there with their arrival time if it's later than now. - Footer: a legend, a "Need a desk? Book one here" button and the settings gear. - Dark theme by default for screens, with a light option. No page scrolling on a TV: if the pods don't fit, show fewer names per pod rather than cutting tiles off. Live updates - Give the page live access to the Robin connector with the mcp capability, using the connector's exact display name (for example "Robin (Workplace)"), and only these tools: get_office_locations, get_current_user_info, get_location_levels, get_building_hours, find_desks, check_desk_availability, find_people, book_desk. - Refresh every 5 minutes by default. Compare reservation ids with the last refresh and highlight new bookings for 30 minutes, in the feed, the pod's squares and the person's name. - If a call fails, keep showing the last good data and put the problem in the status line. Booking from the screen - Tapping a pod with free desks, or the "Book one here" button, opens an overlay: pick a free desk (that pod's, or all pods), then who it's for: the account signed in on the screen, or someone found with find_people. - Book from now until closing. Run check_desk_availability first (with the person's user id when booking for someone else), then book_desk with the bookAs type it returns and forUser set to their email. Say that booking for others needs delegate permission in Robin, and show Robin's reason if a desk can't be booked. - After booking, mark the desk booked and highlight it as new straight away. Never book without a tap on the confirm button. Settings and privacy - A gear that appears when the mouse moves opens settings: building, floor, how to show names (full name, first name and last initial, initials, or counts only), refresh every 2, 5 or 10 minutes, and theme. Save them on that screen only. - Default to first name and last initial. Show "Reserved" for private bookings (visibility JUST_ME) and never their names. Suggest "Counts only" for public lobbies. - If the connector isn't available, show example data and say so, with a button to preview how a new booking is highlighted. Booking in example mode shows what would happen and says nothing was sent to Robin.
Details - Admin week ahead
See what next week looks like at a building from desk bookings and find the days and times you'll need extra help.
Build me a "week ahead" page from Robin for a workplace admin, using our design system. Start with my default building and next week (this week if it's Monday to Friday); don't ask me which. What to pull - get_current_user_info for my default building, and get_office_locations so I can switch buildings. - get_location_levels, then find_desks for each floor with desks (desk id, name, pod, desk types, assignee count). Skip disabled desks. - get_building_hours for Monday to Friday. - check_desk_availability for every desk on each floor, with one window per open day from opening to closing in the building's time zone. Stay under 100 desks and 750 desk-windows per call, and skip days that have already ended. From each desk read its reservations (person, start, end) and, if it has none and can't be booked, the first unbookable reason. - execute_scenario_planning_metric avg_desks_used_per_day for the last 4 completed weeks, grouped by floor, day and checked in. Use it for "a typical Monday" and for the share of bookings that usually check in. If it's refused, leave those parts out and say so. What to show - A one-line headline: the busiest and lightest day, how the week compares with a typical week, and how many things need a plan. - Five day cards: people booked, percent of desks booked, busiest floor, about how many are likely to show up (bookings times the usual check-in rate, never more than the people booked), the typical number for that weekday, and a label: Quiet, Normal, Above usual, Busy or Full. Clicking a card opens that day. - The day panel: each floor as a bar (booked, free, and desks nobody can book), arrivals by half hour from each person's first booking until noon, the busiest pods, and anyone holding more than one desk. When I'll need help Turn the numbers into a short list, each item with the day, what's happening and what to do: - A floor at or above the busy threshold (80% by default): send walk-ins to the floor with the most free desks. - A day 1.5x or more above a typical one: check for bulk or test bookings before staffing up. - An arrival rush (20 or more people starting in the same half hour by default): put someone at reception and the elevators. - People holding more than one desk: how many desks that ties up, and to release the extras. - Bookings on a closed day, bookings that run past closing, and assigned desks with no one assigned (nobody can book them). - When the same flag shows up on three or more days, combine it into one item for the week. Let me mark each item planned, add a short note, and filter by needs a plan, this day, planned or all. Keep the thresholds in a settings panel. Save planned items, notes and settings in this browser only. Data Robin may add later If the Robin connector offers any of these, add them and say which ones were found. If it doesn't, skip them without comment and don't add placeholders or manual entry for them: - Upcoming meetings or room bookings: list next week's meetings by day. Flag important ones by title, size (20 or more people), external guests or executives, and meetings in rooms on busy floors. Add the room, the organizer and the time. - Visits: expected visitors by day and hour, VIPs, groups of five or more, visitors with no host, and visitors arriving during an arrival rush. - Deliveries: expected volume by day, large or signature-required items, and anything uncollected for more than two days. - Activities: catering, cleaning, events and maintenance on the day view. Flag anything that lands on a busy day or blocks a floor. - Tickets: open tickets by building and due date, overdue tickets, and tickets on a floor or room that's booked next week. - Meeting services: services (catering, AV, room setup) attached to next week's meetings. Flag anything unconfirmed and anything due before the building opens. Put each one in the help list with the same day, what and what-to-do format. Live updates and sharing - Give the page live access to the Robin connector with the mcp capability, using the connector's exact display name (for example "Robin (Workplace)"), and only the tools above. Never call a tool that changes a booking. - Let me move between weeks (not before this week) and switch buildings. If a call fails, keep the last data and show the problem in the status line. - A "Copy week summary" button that opens a plain-text summary for Slack or email: each day, what needs a plan and what's planned. - Without the connector, show example data and say so.
Details