Why run space planning through an LLM?

Stack planning has always been the same job: figure out who sits where, test a few ideas, turn the best one into a real plan. LLM interfaces drastically expand the possibilities for planning and offer personalization. Prompting into LLMs lets the model handle the lookups, logic, and drafting of resource allocations, using your office’s real floor plans and org data in Robin.

For those unused to using LLMs (which is totally fine! The technology is new, and there's a small, but exciting, learning curve) the lack of structure in this kind of workflow can be somewhat overwhelming. This guide is intended to flatten the learning curve. We'll start by covering the two workflows most people start with: seeing what you’ve got, and testing hypothetical scenarios. We'll include prompts that you can basically copy-paste, plus a few tips for sharper answers as you go.

Before you start

A few things worth knowing before your first prompt in the LLM.

• No floor plan goes live till you say so. The LLM works in a private draft, allowing you and your colleagues to try things, change your mind, and blow it up and start over if you need to. Your real floor plan in Robin doesn’t move until you review it and hit publish, or tell the model explicitly to publish it.
• There’s no special syntax required to get good results. Just talk normally. “How is Engineering split across our floors?” works exactly like it sounds.
• If you ask vague questions, you'll get options, not a guess. Ask something broad and the LLM should offer a few ways to break it down instead of picking one for you.
• That said, if a real error goes live, you can revert to you previous layout, just ask and use the title of the draft you're looking for.
• A more detailed prompt will almost always get you a better answer. A one-liner will get a solid approximation. A prompt with your actual goal  (what you’re optimizing for, what matters most to your business) gets something built for you. The appendix of this guide has good examples.

What do you do while it’s working?

LLMs can take some loading time to get things set up. Whether that’s invoking and loading the skills and tools initially, or taking some time to construct answers to questions and queries that, as you might expect, take a little time to formulate responses to.

In some cases, that might seem a little much (for example 30 seconds or so to call up the current floor plan of a building), and at other (most!) times it’s a huge value add (for example 45 seconds to make an entire building seating chart based on usage statistics for each department in the building, allocating extra seats for hybrid employees and making sure those neighborhoods are located near their department’s most frequently used spaces).

There is inevitably going to be some waiting while the models construct responses to, ask for clarity on, and analyze your queries. Those waiting periods will often give you, the requester, time to analyze your own questions and find opportunities to define your own thoughts, and skill up on the specificity that helps to get the most out of these tools.

It is our best suggestion to be patient, creative, specific and enjoy the momentary friction.

Getting started, workflow 1: See what you’ve got

The classic starting point: who’s sitting where, right now. The model will pull that straight from real desk assignments, cross-referenced against the org data contained in your employee directory source of truth. Department, job title, and direct manager are all easily visible if you ask. The system will default to department.

Try asking

• “Show me where each department sits across the Fenway building.”
• “Break down Floor 3 by department.”
• “Is Sales split across more than one floor?”
• “Which departments have the most assigned desks sitting empty?”
• “How many seats does Engineering hold compared to its headcount?”

See your stack across a variety of criteria

Department is the default, but it’s not always how a building actually works. For instance, a pod full of VPs from six different departments won’t show up as a pattern if you only ever look by department. 

Ask the LLM to re-cut the same floors by job title (great for spotting a leadership or specialist cluster) or by who people report to (great when a building runs team-by-team, not department-by-department):

• “Show that same floor grouped by title instead of department.”
• “Group Floor 6, Pod 3 by who they report to.”
• “Show me the division of the Fenway building by department, but put everyone with a job title of Director or above on Floor 1.”

Department, title, and reporting line are the three built-in lenses. If you have a custom criteria, such as an organizational function, a project team or, some other “anchor team”? Upload a document (such as as a spreadsheet) showing that breakdown. Tell the LLM how you want people grouped and it’ll build that into a scenario as a named, color-coded “neighborhood” on the floor plan. 

That source document can easily come directly from your HRIS or other source of truth.

Make it personal

Once you’ve put together a first draft, pop into Robin’s scenario planning canvas and drag people between desks directly on the floor plan. LLMs are great at getting you a strong first draft fast; the canvas is where you polish it. 

It is possible to build a sandbox click and drag environment in the LLM itself by asking the LLM, though you may not have quite the location specificity that you have in the map view in Robin. Ask the LLM for what you’d find most helpful and go for it.

What this shows — and what it doesn’t

Stack planning is, first and foremost, a seat allocation report, not a usage report. The stack planning mod can tell you a desk has nobody assigned to it, it can’t tell you whether a desk that is assigned actually gets sat in (no badge or booking data here yet). Both are useful, just don’t mix them up when you’re deciding whether a floor is genuinely overbuilt or just lightly attended.

You can ask such questions when you create your stack plan.

• “Please create a stack plan that creates neighborhoods based on how many users in that department come in at least three days a week. Give a buffer zone of 20% extra desks to each of those neighborhoods.”

Getting started, workflow 2: Test your “what ifs”

Once you know what you’ve got, here comes the fun part. Try scenarios before you commit to them. Large language models are very good at this. They hold a lot of data and show their work, so you see exactly why a scenario does or doesn’t fit before anyone sees a draft.

Each of your scenarios can be saved as a separate draft file to distribute to your stakeholders for easy comparison.

Some examples scenarios and prompts:

Growing a department

• “If Engineering grows by 20 people over the next two quarters, does Floor 4 have room?”
• “We’re hiring 15 people into Design. Where would they fit?”

Consolidating a split team

• “What would it take to get all of Sales onto one floor?”
• “Can we free up Floor 2 entirely?”

You might receive the feedback that Sales holds 50 desks across two floors for 31 people. Moving the smaller group over to be on the same floor almost fits, but the main floor’s nine desks short. Convert some hot desks, or move another team’s desks first? The model will flag the conflicts and provide real options to resolve them.

Cost per head and cost per square foot

Robin doesn’t know your real-estate pricing, so you’ll feed that in: give the LLM the rate and each floor’s (or space's or neighborhood's) square footage, and it’ll do the cost math out loud, right alongside the headcount numbers.

• “Floor 4 is 18,000 square feet at $62 per square foot annually. What’s our cost per head if Engineering, 140 people, is the only team there?”
• “Compare cost per head on Floor 2 versus Floor 5 at these two rates: [rates].”

Robin will never keep your data about real estate cost on platform.

Draft, review, publish

Every change lives in a private draft until you say publish.

You can loop other people in too, as viewers or collaborators, by sharing the draft in Robin or manage users’ viewing permissions from the LLM. 

Choosinf to publish always emails you a summary, and you can choose whether to also notify the people whose seats actually changed.

For the best results, express your goal

The single biggest lever for a better answer is to tell the LLM what you’re actually trying to accomplish, not just what you want counted. 

Compare a bare request to one with intent baked in:

A few more ways to add useful detail:

• Say the goal, such as driving collaboration, reducing real estate costs, consolidating teams, or projecting room to grow. There is lots of flexibility built into the models, so it's encouraged to be precise for the best results.
• Provide constraints. Teams that can’t be split up, floors that are off-limits or a deadline.
• Mention attendance goals if you know it. Employees who are in more or less often changes how you’d size a neighborhood or hot-desk area.
• Describe the shape, not just the count. “A few smaller neighborhoods Design can rotate through” beats “some desks for Design.”

The best way to find out what users can do is to just ask your real, messy question. These models are built to handle a lot more than the examples here. If something isn’t possible yet, you should get feedback from the UI telling you so and providing options to get closer to what you want.

Appendix: Quick-start prompt library

Swap in your real building, floor, department, and names. This should give you a good idea of what's possible and build some momentum to get you comfortable creating plans.