Our scheduling system works like this: a homeowner submits a booking, we run a matching algorithm across available professionals in the right area with the right skills and sufficient time in their day, and we confirm the best match. The whole process takes under 30 seconds for the homeowner. From a user experience standpoint, it works.
The problem is that it is entirely reactive. The scheduling system has no opinion about tomorrow until tomorrow starts generating requests. It does not know that Thursday mornings in Matosinhos tend to be heavy with plumbing calls from holiday lets turning over, or that the week after a major Atlantic weather event sees a predictable spike in electrical inspection requests across Foz do Douro and Cedofeita. It does not pre-position professionals based on where demand is likely to appear. It waits for demand to appear, then scrambles to match it.
This is fine when supply is ample relative to demand. It becomes a problem when the two collide. A cold Tuesday morning in January with a boiler service spike and an already-thin professional availability can produce a situation where homeowners are offered slots 36–48 hours out when the urgency is genuinely higher. That is a market failure — demand and supply are both present, just not coordinated.
Over the past few months, we have been building the early pieces of what a demand-forecasting layer would look like for OSCAR's network. This post describes what we have learned so far and where we still have open questions.
The Data We Have and What It Shows
We have completed job records across all service categories since launch. Each record includes the booking timestamp, job category, service address (aggregated to postal district for analysis), job duration, and the professional's origin point. From this data, some patterns are clear and some are murky.
Clear patterns: demand in the CP4150 postal district (covering much of Matosinhos and nearby coastal areas) peaks on Thursday mornings and Monday afternoons. Demand across the central Porto districts (CP4000–CP4050, covering Bonfim, Cedofeita, and Santo Ildefonso) is more evenly distributed across weekdays with a modest Friday afternoon spike. Demand for electrical work specifically shows a secondary peak in the first two weeks of January — consistent with Christmas lighting installation causing tripped breakers or revealed wiring issues.
Less clear: predicting the magnitude of a spike, not just its timing. We know that November and January tend toward higher demand for boiler services. We do not know — not with confidence — whether a given November will produce 20% more bookings than a quieter month or 40% more. The variance is large enough that pre-positioning based on expected magnitude risks being wrong in a way that creates costs without benefits: professionals blocking out time for anticipated demand that does not materialise.
What Pre-Positioning Would Actually Mean
Pre-positioning in this context does not mean moving professionals physically to a location before demand arrives. It means influencing their availability schedule. Specifically, it means contacting professionals with a forecast — "we expect Thursday morning in Matosinhos to be heavy on plumbing calls, would you consider opening availability for that window?" — and then, if they agree, prioritising their routing towards that area when jobs start arriving.
This is a soft signal, not a hard constraint. We are not dispatching professionals to stand by somewhere. We are nudging availability decisions with demand information the professional would not otherwise have access to. A plumber who knows there will be strong demand in Matosinhos on Thursday can make an informed choice about where to position their schedule, and they benefit directly if the prediction is accurate — more efficiently clustered jobs, less dead travel time.
The tool for this does not exist yet. What exists is the data layer and the forecast model. The interface that surfaces forecasts to professionals and allows them to act on them is in development.
The Professional Incentive Problem
For demand forecasting to translate into actual supply pre-positioning, professionals have to trust the forecasts enough to act on them. If we tell a professional that Paranhos will be busy on Wednesday and they clear their schedule accordingly but the demand does not materialise, they have lost earnings they might have had from jobs elsewhere. That erodes trust in the forecast signal quickly.
We are not planning to launch demand signals until the forecast accuracy is high enough to justify acting on. Currently, our day-of-week demand patterns are reliable enough at the district level — the signal has been consistent over 12 months of data. Our week-level magnitude forecasts are not reliable enough yet. We are being explicit about that distinction because it shapes what we build first: a tool for routing existing availability toward likely demand zones (using the reliable day-of-week patterns) rather than a tool for expanding availability based on magnitude predictions we are not confident in.
We will not tell a professional "Thursday will be busy, clear your diary" until we have enough historical data to back that claim with a confidence interval we are willing to stand behind. We are not there yet.
The Geographic Granularity Question
Porto's street network creates scheduling challenges that aggregate demand forecasts do not capture well. A professional available in Matosinhos can reach Foz do Douro in 15 minutes on the IC1 outside rush hour, but the same trip takes 35–40 minutes on a weekday morning between 08:00 and 09:30 as VCI and the A28 interchange back up. A professional who the system believes is "in the area" for a Bonfim job from their previous job in Campanhã may be 50 minutes away if the Ponte do Freixo is congested.
Our current scheduling system accounts for travel time using historical traffic data by time-of-day and route. What it does not yet account for is real-time event disruption: the tram maintenance that closes Rua de Santa Catarina on a Tuesday, the Matosinhos street market that blocks the parallel routes through the municipality on Saturday mornings. These events compress the effective supply in a geographic zone in ways that aggregate forecasting cannot anticipate.
The fix for this is real-time traffic integration, which we have prototyped but not yet deployed at scale. The prototype uses ANSR (Autoridade Nacional de Segurança Rodoviária) incident data and Câmara Municipal do Porto event data to flag known disruptions and adjust routing estimates dynamically. Getting it into production reliably is a Q3 2026 target.
What We Are Not Trying to Build
It is worth being clear about the scope of what we mean by predictive scheduling, because "demand forecasting" can mean very different things at different scales.
We are not trying to build a system that micro-optimises professional routes to the degree where the professionals feel like they have no schedule autonomy. A professional who feels that the platform is dictating their movements hour-by-hour will leave the platform — and that outcome is worse for everyone than a slightly less efficient schedule. We want to give professionals better information so they can make better decisions. We do not want to make decisions for them.
We are also not aiming to build a system that maximises revenue-per-professional-hour at the expense of job quality. A professional who is racing between eight tightly scheduled jobs will do worse work than one who has reasonable breathing room. Our scheduling optimisation has a minimum job completion window built in — we will not book a professional into a slot that our time estimates say they cannot complete comfortably. We are optimising for sustainable professional utilisation, not peak utilisation.
The Honest State of Play
The current scheduling system serves us well for the demand volume we have today. It will start showing strain at roughly twice current volume — that is our rough estimate based on how the matching queue behaves on peak days now. We are building toward a forecasting layer specifically so that strain does not hit us as a surprise.
The forecasting model is live in analysis mode — it is generating predictions but not yet surfacing them to professionals or affecting scheduling decisions. We expect to move it into a limited pilot, covering two or three professionals who have expressed interest in receiving demand forecasts, in Q3 2026. From there, we will learn from actual professional behaviour in response to the signals before deciding whether to expand it across the network.
We have written about our scheduling thinking in earlier posts — specifically the original scheduling architecture post from November 2024 and the same-day logistics post from April 2025. This post continues that thread. Expect more from us on this as the pilot progresses.
