A decision deadline is counted back from the site schedule: kitchen and bathroom fix where the services run, and those must sit in the floor before the screed is poured.
The date a buyer has to pick a kitchen does not come from an administrative calendar. It is counted back from the moment that kitchen has to stand on site, with the ordering and manufacturing time in between. Customer care or project management sets it, inside the overall site schedule.
On large projects it happens in waves, per phase or per building, and sometimes it depends on whether the unit has been sold yet.
Kitchen and bathroom almost always come first, and not because they have the longest lead time. They fix where the pipes, drains and connection points go, and those services have to sit in the floor before the screed covers them. They also govern the floor choice, because dimensions and alignment follow from them.
| Step | What gets decided | Why it cannot wait |
|---|---|---|
| Kitchen and bathroom | appliances, layout, connection points | fix where the services run |
| Services | pipes, drains, sockets | must sit in the floor before the screed |
| Screed | nothing further | changing anything now means breaking concrete |
| Floors | material, format, laying direction | size and alignment follow from step 1 |
The screed is not a construction phase like the others. It is the moment a pencil line turns into concrete.
You collect approvals digitally by giving every choice its own deadline, its own proposal and its own status, then showing those three to the buyer together. The buyer sees a sequence instead of scattered questions: which decision has to land when. Reminders go out relative to that deadline, for example a week before and two days before.
What the buyer sees alongside the date does more work than the date itself. Each decision can carry a short note saying why it has to land now and what it is holding up. A buyer who reads that their choice is blocking the electrician answers differently from one who sees only a deadline.
On the developer’s side that produces a status per choice, across every unit. Green means approved. Yellow means a subcontractor has uploaded a proposal the buyer has not answered yet. You see a deadline coming before it passes, not after.
What that is worth has less to do with the overview than with the build sequence behind it. Kevin Cosijn, project leader at contractor Van Tornhaut, puts it this way:
“Those colors indicating the state of a decision help customers make their decision faster. I feel like they’re triggered to proceed in the decision-making process quicker. As a project leader, that’s important because I need all those decisions on time so that everyone can prepare and start the next phase in the construction process.”
Kevin Cosijn, project leader at Van Tornhaut
Van Tornhaut works alongside property developer Volus, which tracks every buyer decision the same way instead of in a spreadsheet. How the two run that together is in the Volus success story.
Across 111,283 decisions that carried a deadline, sat on a sold unit and were visible to the buyer, 43.1% were approved after that deadline. Measured on 2 September 2026 in Ziggu’s own product data, across more than 150 construction and property companies.
That figure is not one company with a broken process dragging the rest. Among the 108 companies with at least fifty such decisions, the typical one runs 45.1% late, and the middle half sits between 31% and 61%. The largest developers do better than average, which is what pulls the pooled number down.
Buyers are not slow, though. Of 177,647 proposals, half were approved within 3.5 days. The average is 29.6 days, and the slowest ten percent take more than 75 days.
The gap between 3.5 and 29.6 is the whole story. Most buyers decide straight away. A small group stalls, and that group decides whether the screed can be poured on time.
So a late choice rarely costs only that choice. It moves an installer, pushes the screed back, and with it the floor layer and everything after. That is also why an average says so little here: your schedule hangs on the slowest five percent, not on the median.
Some developers work in waves. Miss the deadline and you move automatically into the next one, with a different schedule and possibly a later handover date. The choice often falls back to the standard specification.
In practice it rarely goes that neatly. The developer follows up, calls, and gets the choice in anyway, sometimes with a penalty clause in the contract behind it. The system does not decide anything. It only makes visible who needs a phone call.
Set a deadline before the buyer knows their budget or their layout and you do not get a choice, you get an “I don’t know yet”. That has to be rescheduled, and from then on the buyer believes the next deadlines a little less. A deadline set too early costs you not one choice but every choice after it.
So the moment of publishing matters as much as the date. A decision should appear when it becomes relevant, tied to the milestone it belongs to, instead of all of them at project kickoff. Open everything at once and the buyer looks at forty pending choices and makes none.
The sequence in the table above is the best starting point for that: whatever fixes the services opens first. The choices that only matter after the screed can appear months later.
A decision list is not only a scheduling instrument. It is also the one place a buyer can quietly see what is still possible, without anyone having to ring them up to offer it.
An optional list that stays open until handover does that work by itself. An extra remote for the garage door, one more socket, a different tap: small things a buyer is happy to add but rarely asks for. Show the choice next to the allowance and the quoted amount, and it sells without pushing.
The same overview is then two things at once: which choice holds up the site, and what has not been charged yet. Decisions and approvals does both.
