Coworking Space Software: Why Desks, Doors and Billing Never Agree

Why booking and access software makes or breaks a coworking operator

Your revenue is a function of two numbers: how many desks are sold, and how many hours your meeting rooms are actually occupied versus booked. Everything else is decoration. And most operators cannot answer either number accurately on a Tuesday afternoon without someone opening a spreadsheet.

Here is the stack most multi location operators are running. Nexudus or OfficeRnD or Cobot for memberships and billing. Kisi or Brivo or Openpath for doors. Stripe or GoCardless for payments. Xero or QuickBooks for accounts. Slack or Circle for community. Maybe a Zapier layer duct taping three of them together. Each one is competent alone. The problem is that none of them agree on what a member is. A member cancels in Nexudus, but their Kisi credential lives on until a community manager remembers to revoke it. Someone books a room for 90 minutes, uses 20, and the room stays dark and unsellable because nothing releases it. An enterprise client signs a 12 month deal for 14 desks with a 3 month ramp and two free meeting room hours per desk per month, and that contract lives in a PDF in someone's email while the billing tool charges a flat number that a human corrects manually every cycle.

The concrete scene: it is the 2nd of the month at a 5 location operator with about 900 members. The finance lead has a spreadsheet open with 60 to 90 manual credit note and adjustment lines. Overage hours that Nexudus counted but the enterprise contract said were included. A member who upgraded on the 14th and got charged both plans. A print quota nobody reconciled. That person burns two to three days per month on this, every month, forever. Call it 30 days of a finance salary per year, plus the leakage they never catch: rooms sold at member rate that should have billed at guest rate, day passes redeemed twice, credits that expired but were honoured anyway. In the operators we have audited, that leakage runs into low single-digit percentages of revenue, and on a $6M run rate it is invisible because nothing in the stack is designed to detect it.

Problem: your room inventory is a calendar, not an inventory

Off the shelf tools model a meeting room as a Google Calendar with a price attached. That is fine for a single site with 4 rooms. At 5 sites with 40 bookable resources, it breaks in specific ways: no no-show release, no dynamic pricing, no partial cancellation, no understanding that Room 3 at Shoreditch and Room 3 at Kings Cross are substitutes for a member who just needs 8 seats and a screen at 2pm.

A member books the 12 person boardroom for 4 hours, then holds a 40 minute call in it. Nexudus and OfficeRnD both count that as a fully utilised booking. Your utilisation dashboard says 78 percent. Your actual seat-hours occupied is closer to 40 percent, and you are turning away paid guest bookings for a room that is empty. The off the shelf tool cannot fix this because it has no signal from the room. It has no idea whether anyone walked in.

A custom build models rooms as inventory with a state machine, not calendar entries. Resource attributes: capacity, audio visual kit, natural light, floor, site, and a substitutability graph so the booking engine can offer alternatives. Occupancy signal from an inexpensive passive infrared (PIR) or people-counting sensor, or from door badge events you already have from Kisi, feeding a no-show rule: no presence detected 12 minutes in, the booking auto-releases back to inventory, the member gets a notification and a partial credit, and the room reappears on the availability API. Then price it: peak hour boardrooms at 1.4x, Friday afternoons at 0.6x, driven by a rolling 8 week demand curve per resource per site. We have seen operators recover 15 to 25 percent more sellable room-hours purely from no-show release, before touching pricing.

Problem: enterprise contracts do not fit in a plan dropdown

The revenue you want is the 20 desk, 24 month enterprise deal. The tool you have models memberships as a plan with a monthly price. So the moment you sign a deal with a 3 month ramp from 8 desks to 20, two free room hours per desk per month that pool across the team and roll over one month, a 4 percent annual uplift, a 45 day break clause, and a 5 desk flex allowance, you have left the software behind. It goes into a PDF. Then it goes into someone's head. Then that person leaves.

Nexudus and OfficeRnD cannot fix this because their data model is plan-per-member. Every enterprise nuance becomes a manual credit note. When the account manager renegotiates in month 14, nobody can reconstruct what was actually agreed versus what was actually billed, and you discover you have been giving away 40 room hours a month for free for a year.

The custom build treats the contract as a first class object: a versioned agreement with dated line items, entitlement pools (room hours, print, guest passes, parking) with their own expiry and rollover rules, ramp schedules, uplift triggers, and notice terms. Billing becomes a rating engine that reads the contract, not a human reading a PDF. Every invoice line carries a traceable link back to the contract clause that produced it, so when the enterprise client's procurement team queries a charge, your account manager answers in 30 seconds instead of 3 days. This is also where document extraction earns its cost: pipe the signed PDF or DocuSign envelope through an extraction model that pulls term, desk count, rate, ramp, entitlements, and notice period into structured fields, and put a human review screen in front of it. On migration we have used this to structure several hundred legacy contracts in days rather than months, with a reviewer confirming each one.

Problem: doors, memberships, and money live in three systems that never reconcile

The access control tool has its own user list. The membership tool has its own. Stripe has its own customer objects. When a member downgrades from a dedicated desk to a hot desk plan with 8 days a month, three systems need to change and typically one to two do. The result is people badging into a building they are no longer paying for, and the reverse: a paid member who cannot get through the door at 8am on their first day because the credential provisioning was a manual task on someone's to-do list.

Zapier does not fix it. Zapier fires a webhook and hopes. It has no idea what to do when the Kisi API is down for 40 seconds, no retry semantics you can reason about, no audit trail your insurer will accept, and no way to answer "who had physical access to Floor 3 between 19:00 and 22:00 on the 14th" when a laptop goes missing.

The custom build inverts the ownership. One canonical member record with an entitlement state, and everything else is a projection of it. Access rules derive from entitlements: plan tier, site, floor, day-pass balance, contract status, payment status. When a subscription goes past due at day 14, access downgrades to business hours automatically. When a contract terminates, credentials revoke the same second and the event is logged. Integrate at the API level with Kisi, Brivo, or Openpath rather than through a no-code hop, with an outbox pattern so provisioning is retried until it succeeds and never silently lost. Add a reconciliation job that runs nightly and reports drift: every credential in the door system that has no matching active entitlement. In our experience, most operators find between 20 and 80 ghost credentials on the first run of that job. That number alone usually justifies the project to a board.

Problem: tours and after-hours enquiries go to a form nobody answers until Monday

Half your enquiries arrive outside staffed hours, and a good chunk of them are from someone comparing you to two competitors in the same 20 minutes. Your website form emails a shared inbox. Your community manager replies at 9:15 on Monday. The deal is gone.

Off the shelf tools give you a form and a CRM (Customer Relationship Management) sync. They do not know that Kings Cross has three 4 person offices free from the 1st, or that the 6 desk suite is under offer, so they cannot answer the only question the prospect asked: do you have space for six people from March, and what does it cost.

This is where an AI layer is worth building, because it sits on top of your real inventory and pricing rules rather than on a knowledge base of marketing copy. An assistant with read access to live availability, pricing bands, and tour slots can answer the space question at 11pm, quote a real range with the discount floor your team sets, hold a unit for 24 hours, book the tour into the community manager's calendar, and hand over a structured summary: headcount, move-in date, budget signal, objections raised. Where operators see the return is not the novelty. It is that response time on out of hours enquiries drops from the next staffed morning to under a minute, and tour bookings from web traffic lift because the prospect never has to wait to find out if you can even house them.

What this costs and how long it takes

These are Digital Heroes delivery bands from our own project history, not industry estimates.

A focused first release typically runs $60k to $130k and ships in 12 to 16 weeks. That is: canonical member and entitlement model, resource inventory with booking and no-show release, one access control integration, Stripe or GoCardless billing with a real rating engine, and an operator dashboard. It is enough to kill the monthly spreadsheet and stop the credential drift.

A full platform runs $150k to $400k phased across 6 to 12 months: multi entity billing across sites and legal entities, enterprise contract engine, member mobile app with mobile credentials, dynamic pricing, broker and referral commission tracking, visitor management, and accounting integration.

What drives price up in this category specifically. Hardware is the big one: every access control vendor has its own quirks, and mobile credentials via Bluetooth or NFC add device certification work that a pure web build never touches. Multi currency and multi entity billing, common the moment you cross a border, roughly doubles the billing scope because of value added tax and goods and services tax treatment per entity. Migration from Nexudus or OfficeRnD is never a CSV import: historical invoices, part-period proration, and credit balances need reconciling to the penny, and that is usually 3 to 5 weeks on its own. And if you want the booking engine to serve a public marketplace or broker feed, availability has to be correct under concurrency, which means real locking and real load testing.

Build or buy: take the honest position

Buy if you are under roughly 4 locations and 400 members. Nexudus at its published per-member pricing, OfficeRnD, or Cobot will cost you an order of magnitude less than a build, and at your scale the manual work is 4 hours a month, not 3 days. Spending $90k to fix 4 hours a month is a bad trade. Put it into sales. Buy also if your model is homogeneous: everyone on the same plan, no enterprise contracts, one access vendor.

Build when these signals appear together. Your finance lead is spending more than two days a month on manual adjustments. More than 25 percent of revenue comes from enterprise contracts that do not fit the plan model. You are running more than one access control vendor across sites, or you are about to inherit one through an acquisition. You have already paid for two custom development add-ons on top of your platform and are still not getting what you need. Or you are a landlord or private equity backed operator where the coworking software is the operating system for the asset, and the exit valuation depends on demonstrably clean, auditable occupancy and revenue data that a shared SaaS tenant cannot give you.

The signal that matters most: when the tool starts dictating what deals you are willing to sign. The day your sales lead says "we can't do a ramped contract because the system can't bill it," you are no longer using software, you are being used by it.

How to choose a developer for coworking space software

Ask them to model an enterprise contract on a whiteboard, live. Not a wireframe. The entity relationships between organisation, contract, contract version, entitlement pool, member, and invoice line. If they draw a member with a plan_id foreign key, they have never built this and you will pay for their education.

Ask which access control APIs they have shipped against in production, by name, and what broke. The right answer includes specifics: Kisi group provisioning limits, Brivo token expiry behaviour, what happens to a mobile credential when a phone goes offline. Vague enthusiasm about integrations means they have read the docs and nothing more.

Ask how they will reconcile the migration. Specifically: how do they prove that the closing credit balance for every member in Nexudus matches the opening balance in the new system, and what the rollback plan is if the first billing run is wrong. Anyone who says "we'll import the CSV" should be disqualified on the spot.

Ask who owns the code, the infrastructure accounts, and the data, in writing, before kickoff. You want the repository in your organisation from commit one, your own Stripe and cloud accounts, and no runtime licence on anything they wrote for you. If they are precious about the source, they are planning to rent you your own building's operating system.