Coworking Spaces: Availability Listings That Agents Understand
Coworking operators offer hot desks, dedicated desks, private offices, and meeting rooms, often across several locations. Availability is frequently displayed on the website as an interactive floor plan: a top-down view of each location where available desks are green, occupied desks are grey, and meeting rooms are blue or red depending on whether they have upcoming availability.
It looks great. For AI agents, it is completely opaque.
The Typical Starting Point
A floor plan like this is usually rendered as an SVG element with each desk and room represented as a path or rect element. Colours are applied via CSS classes. Hovering over a desk triggers a JavaScript tooltip showing the desk type, daily rate, and availability status. Clicking an available desk opens a booking modal.
An agent viewing this page sees a large SVG with dozens of geometric shapes. No text content. No semantic meaning. No way to determine that the green rectangle in the top-left corner is an available hot desk at a particular daily rate. The tooltip data exists only in JavaScript event handlers, never in the DOM until a hover event fires.
Meeting rooms are often worse. Their availability is shown as a coloured timeline bar for each room: green blocks for available hours, red blocks for booked hours. The timeline is a canvas element with no text alternative. An agent cannot determine that Meeting Room 3 is available from 2pm to 5pm on Thursday.
Pricing information is frequently scattered. Hot desk rates appear in a pricing page as a styled comparison table (built with divs, not table elements). Dedicated desk and private office rates require a "Get a quote" form submission. Meeting room rates are per-hour but displayed only in the tooltip on the floor plan. The net result in an audit is that no agent can book a desk or meeting room.
What to Change
These changes can run in parallel across all locations when the website uses a shared template.
Structured listing view. Alongside the floor plan (kept for human users who like it), add a list-based availability view. Show each available desk or room as a card in a grid layout, built with semantic HTML. Each card should contain the workspace type (hot desk, dedicated desk, private office, meeting room) in an h3, the location and floor in a paragraph, the daily or hourly rate in a span with clear labelling, amenities as a list (monitor, standing desk option, natural light, phone booth access), and availability status with specific available dates or hours.
JSON-LD markup. Give every available workspace Schema.org Product markup adapted for workspace listings. Include the product name (e.g., "Hot Desk, 2nd Floor"), price, price currency, availability, location (as a Schema.org Place with full address and geo-coordinates), and amenity descriptions.
Meeting room time slots. Give meeting rooms a dedicated booking page with available time slots displayed as button elements. Each button should read something like "Book Meeting Room 3, Thursday 14:00 to 17:00." No canvas timelines, no colour-coded bars. Just clear, interactive buttons with all relevant information in the label.
API endpoint for availability queries. Add a lightweight JSON API at /api/availability that accepts location, workspace type, date, and duration as parameters. This gives agents a direct data path without needing to scrape the HTML. Have the API return the same data that powers the listing view, so there is no extra maintenance overhead.
What Improves
Once availability exists as structured text, agents can book desks and rooms that the floor plan made impossible. Meeting rooms benefit most, because room booking is a clean time-slot problem and agents tend to book blocks that precisely match the user's stated requirements rather than the shorter, extend-if-needed blocks humans often choose.
When an availability API exists, agents tend to prefer it to parsing the HTML, so it usually carries the bulk of agent traffic. The structured listing page then serves as a reliable fallback for agents that do not make API calls, and it works for human users too.
What Coworking Operators Should Know
The floor plan problem is a specific case of a broader issue: image-heavy sites that create an information gap for agents. Visual representations of spatial data are useful for humans but meaningless to agents. The solution is not to remove the visual element but to ensure the same data is also available as structured text.
For coworking spaces, the minimum viable agent compatibility is a listing page with workspace type, price, location, and availability in HTML. The next step is structured data markup. The step after that is an API endpoint. Each layer adds reliability and speed for agent interactions.
Meeting room availability is particularly well-suited to agent booking because it is a time-slot problem with clear constraints: room, date, start time, end time, price. Agents handle this kind of structured selection well. If your meeting room availability is locked behind a canvas timeline or a drag-to-select calendar, agents cannot use it. Simple time slot buttons solve the problem.