FeaturesHealth & SafetyIntegrationsCountriesPricingResourcesLog inStart free trial
SKEDS / Resources / Scheduling
Scheduling

Scheduling multi-day projects among the small stuff without losing either

By the SKEDS Team · 22 October 2026 · 6 min read

Mixing project work with service work is where trade scheduling actually gets hard, and the forums know it: "The bathroom reno swallows my best two guys for a fortnight, service calls keep coming, and rescheduling day 8 of 12 broke everything downstream." Calendars built for events treat a twelve-day job as twelve unrelated bookings, which is precisely how the plasterer arrives before the waterproofing cures. Running both kinds of work off one board takes three structures: real multi-day blocks, dependencies you can see, and a deliberate split between project crews and the service stream.

Book blocks, not fragments

A multi-day project entered as separate daily bookings will desynchronise the first time anything moves. Enter it as what it is: one job spanning a date range, assigned crew, visible as a continuous block on the board. Moving the block moves every day together; extending it when the tiler finds rot extends the whole tail. The fragments-versus-block distinction is the root cause behind most of the multi-day horror threads, and it is a data-model fix, not a discipline fix.

Make the dependencies visible

Inside any renovation lives a sequence: demo, rough-in, close, finish, and between some steps, hard waits, cure times, inspections, deliveries. Represent the stages as linked phases with the waits marked, so the person dragging Wednesday can see what Wednesday holds hostage. Even a lightweight version, phase checklists on the block plus noted wait days, prevents the classic cascade failure where one moved day silently reorders the trades, the scenario our rescheduling guide flags as the most expensive kind of move.

Split the fleet: project crews and a service stream

The pattern that survives contact with reality: dedicate who the project needs, and protect at least one tech as a pure service stream for the callouts, quotes and small jobs that pay the bills between projects. The service tech's board carries the float slots; the project block carries none, because its buffer lives at the end as contingency days. Cross-pollination is deliberate, not chaotic: if the project stalls on an inspection, the board shows the freed pair, and standby small jobs flow to them for exactly the stall window.

Buffer at the end, report from the middle

Pad each phase and the padding gets consumed invisibly, Parkinson's law on a job site. Instead, book phases honestly and hold visible contingency days at the block's end; unused, they release early, used, they were the plan. Meanwhile the daily field data, clock-ons, photos, phase checklists ticking over, gives the office a live percent-complete without site visits, and gives the customer a proactive progress message that pre-empts the where-are-we call. Project management bodies like PMI formalise all this for towers and tunnels; the renovation-scale version is the same physics with fewer meetings.

Money follows the phases

Multi-day work strains cash unless invoicing tracks the block: deposit at booking, progress claims at phase gates, final on sign-off, the structure from our progress payments guide. Because phases live on the job, each claim assembles itself from completed checklists and photos, evidence attached, disputes pre-empted. The project that runs three weeks should never be the project that waits five more for its money.

Frequently asked questions

How should a two-week job appear on the schedule?

As one continuous block with a date range, assigned crew and phase checklists inside it, never as fourteen separate bookings. Blocks move, extend and notify as a unit, which is the entire difference between adjusting a project and re-planning one.

How much contingency should a project block carry?

Ten to twenty percent of duration for renovation-scale work, held visibly at the end of the block rather than padded into phases where it evaporates. Unused contingency releases early and delights the customer; used contingency was simply the plan working.

How do I keep service customers happy during big projects?

Protect a dedicated service stream, at least one tech who never gets swallowed by the project, carrying the float slots and the standby list. Project stalls then become service capacity instead of idle hours, and your bread-and-butter customers never learn you were busy.

The bottom line

The pattern across every topic on this blog repeats here: the businesses that win are not working harder, they are keeping better records and letting systems carry the routine. Start with one change this week, measure it for a month, and let the results argue for the next one. And if you want the whole loop, scheduling, field app, safety and invoicing in one place, start a free SKEDS trial and test it on a real week of your own jobs.

Key takeaways

  • Enter projects as date-range blocks, never daily fragments
  • Mark phase dependencies and cure-time waits on the block
  • Dedicate project crews; protect a service stream with the float slots
  • Hold contingency at the block end, not hidden in phases
  • Invoice at phase gates with evidence auto-attached
Just Skeds it.

Stop running the job from a spreadsheet

Schedule your crew, run jobs from the van, and invoice the moment they are done. Free for one user, forever.

Start free trial