Table of Contents
Undercurrents, hosted by Hector Kolonas, dedicated its latest edition to dynamic pricing in coworking. These are the ideas from the edition that stood out to us most, alongside a closer look at how dynamic pricing actually works inside Nexudus.
Let's dive in. 🙂
Pricing was never really fixed
Dynamic pricing sounds like a new idea, another AI trend arriving in coworking. But most operators have been practicing some version of it for a long time: charging more for meeting rooms with high demand, adjusting rates based on what competitors charge, applying a discount to members with a longer commitment, or negotiating differently when only one office is left. None of this was automated, and none of it was labeled as a dynamic pricing strategy. There was no sophisticated data model behind it, just judgment built on experience.
What has changed is how, and how often, pricing moves. Technology can now evaluate hundreds of booking signals at once, something no person could reasonably track by hand, and that is what allows pricing engines to help operators pursue different goals: maximizing revenue per available resource, protecting premium inventory, or steering demand away from busy periods.
The manual era, the rule-based pricing
In the Dynamic Pricing Undercurrents edition, Adrian Palacios, co-founder and CTO of Nexudus, described how pricing worked in Nexudus a decade ago:
"Ten years ago, pricing in Nexudus was pretty simple. You would have types of rooms or types of resources, as we call them. And then you had an hourly price, a half day price, a daily price. That worked."
As the coworking industry grew, operators started analyzing their own data to spot booking patterns, quiet Fridays, slow Thursday evenings, and building manual rules around them to set prices. It worked, but it took a lot of effort, since every resource and every day had a different usage pattern to account for. As Adrian put it:
"You need to be good at understanding the data and translating that into rules that actually make sense. And by the time you finish, the reality of day to day may have changed, or you may go into summer and the demand is completely different."
Some operators ended up managing hundreds of individual prices, adjusting them by 5 percent or 10 percent whenever conditions shifted. It was a manual process from start to finish, analyzing the data, deciding on prices, and monitoring how they converted, and the maintenance simply was not sustainable at that scale.
Dynamic pricing as the natural next step
We understand dynamic pricing as the natural evolution of rule based pricing. The logic behind it is the same one operators already applied by hand: detect the quiet and busy days and hours, define the boundaries, setting minimums and maximums, and adjust price accordingly based on the goal. What changes is that the system now does this automatically, and, more importantly, weighs far more variables at once than a person could realistically track.
Adrian put it this way:
"It's a very natural evolution of any pricing system. You want the flexibility, but not the burden of having to monitor that flexibility and adjust it all the time."

*Image created by Hector Kolonas for Undercurrents: Dynamic Pricing.
That flexibility is exactly where AI adds real value. Rather than reacting to a single signal, a pricing engine pulls together multiple data sources at once to shape the best strategy for each resource: booking history across every resource in the space, external events, competitor pricing, holiday context for periods that reliably push demand up or down, broader business context such as location and size, and temporal patterns across time of day, day of week, and month. Taken together, these inputs let the engine land on the right price for each slot.
The model also keeps improving with use. The longer an operator runs it, and the more bookings it processes, the sharper the pricing becomes.
Trust in dynamic pricing is the real challenge
Trust needs to be built on two sides. On the operator side, adoption starts with clearly understanding how dynamic pricing actually works in their spaces, which means the pricing engine has to be transparent about how, and why it arrives at a price, not just present it as a black box. On the member side, trust means something closer to what any customer expects from a business: consistency.
Coworking is not a transactional business. It is built on community, belonging, and hospitality, and customer trust is what keeps that kind of business sustainable. That is exactly what makes deploying dynamic pricing the harder challenge.
The tension sits between transparency and revenue optimization. The real question operators face is how to deploy dynamic pricing without eroding member trust.
Customers do not necessarily expect prices to stay the same forever, but they do expect to understand why a price changed, and what factors are influencing it. When that explanation is missing, people tend to assume the worst, which is exactly what communication needs to prevent. Communication about pricing is not a step that happens after the price changes. It is part of the pricing strategy itself.
This is also why, as Hector notes in the edition, several operators draw a clear line between members and visitors. Members get fixed, predictable pricing. Dynamic pricing is reserved for external, one off bookings, where variable pricing is already an expected part of the experience. It is a simple way to capture the commercial benefit of dynamic pricing without disrupting the relationship the business depends on most.
One thing worth exploring further, and that we believe will matter going forward, is the role of UX inside the product itself in communicating dynamic pricing clearly enough to build trust, on both sides, operator and member.
Finally, we want to take a closer look at how dynamic pricing actually works inside Nexudus.
How dynamic pricing actually works inside Nexudus
Dynamic pricing in Nexudus adjusts booking rates automatically based on predicted demand, removing the need for operators to reprice resources by hand. Underneath it is a demand forecasting machine learning model trained on each space's own historical bookings, built from several feature groups working together:
Booking history for every resource in the space.
Forecasted bookings, already confirmed future bookings that reduce remaining capacity.
Holiday context, capturing periods that reliably push demand up or down.
Broader business context, such as location and size.
Temporal patterns across time of day, day of week, and month.
Resource specific features, including the facilities and amenities tied to what is being booked.
Together, these give the model a granular read on when, and why, a given resource tends to get booked.
Pricing in Nexudus does not hand complete control over to the AI model. Operators define the boundaries themselves, setting minimums and maximums, teaching the tool how they want their business to price.
Pricing rules can be set at two levels. A space level rule applies across every resource at once. A rate level rule targets resources on a specific rate. When both exist, the rate specific rule takes priority, fine tuning the baseline the broader rule establishes.
In practice, dynamic pricing applies through two scenarios, which can be combined:
Demand-based pricing. Prediction models trained on each resource's historical data classify every time slot over the next four weeks as high, average, or low demand, and rates adjust accordingly. A resource priced at 50 euros an hour with a 10 percent high demand increase bills at 55 euros during peak periods. The same logic works in reverse, with low demand discounts steering customers toward the hours an operator most wants to fill.

Last-minute pricing. Rates adjust when a customer books a resource close to the start time. This can be gradual, with the price climbing progressively up to a set percentage over a chosen window, for example up to 20 percent more if the customer books within 3 hours of the start time. Or it can be fixed, applying a flat percentage adjustment inside that window, for example a 20 percent increase on any booking made within 3 hours of the start time.

In effect, these settings are the guardrails operators define for themselves, as mentioned earlier. The AI model decides when demand is high, low, or average, based on the historical booking pattern of the space. The operator finally decides how much that should actually cost.
For the demand prediction model to work well, it requires at least 3 months of historical booking records, and as mentioned before, its performance keeps improving as it learns from new data. The more historical bookings a resource has, the better the prediction becomes.
Where should you start?
If an operator is considering deploying dynamic pricing, a phased rollout tends to work better than switching it on everywhere at once.
Start with external visitors booking a resource, not members, and ideally with resources that see lower occupancy to begin with. The goal at this stage isn't maximizing revenue yet. It's understanding how the pricing engine actually behaves, and building trust in it, both the operator's own and their team's, before it touches anything more sensitive.
A practical way to do this is, once the resources for the pilot have been selected, to set thresholds close to 1, so the increases and discounts applied stay close to the base price rather than swinging widely. This keeps the first phase low risk: it lets the operator observe how the engine reads demand and adjusts pricing without exposing the business to large price movements while still learning how it behaves. Once the engine's responses have been validated and the operator feels comfortable with it, those thresholds can be progressively widened and expand dynamic pricing to the rest of the resources.
From there, operators should define a success metric before scaling further, whether that's monthly revenue, booking volume, or occupancy, and track booking conversion over the following month to see whether it's actually moving in the right direction. Without a clear metric, it's hard to tell whether the engine is helping or simply changing prices.
That leaves two questions worth answering before getting started:
What is the first goal in deploying dynamic pricing? Maximizing revenue per available resource, protecting premium inventory, smoothing demand, or something else?
Which resource will be the starting point for testing, and what will the success metric be?
That's it for today. See you in two weeks! 🙂


