Tentative vs. confirmed bookings: How to avoid overbooking

A tentative booking (a soft allocation in Birdview) holds a person for work that is not yet signed, while a confirmed booking (a hard allocation) commits that person to contracted work. To plan against pipeline without overbooking, give named holds only to high-probability deals, cap how much tentative load one person carries, put an expiry on every hold, and settle conversion conflicts with a priority rule agreed in advance.

Most services firms do not overbook because they lack data. They overbook because pipeline and delivery live in different places. Sales sees ten live opportunities, and the resource manager sees a schedule that only shows signed work. One Director of Professional Services at an IT consulting firm put it plainly on a discovery call with us: “I see 10 opportunities. I don’t know who’s available.”

Tentative bookings close that gap, but only when they follow rules. Without rules, soft holds pile up, everyone looks busy on paper, and the first two deals that close at once trigger a weekend of reshuffling. “Tentative” and “soft” mean the same thing in this article, and so do “confirmed” and “hard.” Birdview uses the terms soft and hard allocation.

What are tentative and confirmed bookings?

A tentative booking flags expected demand on a person or role before the contract is signed; a confirmed booking commits a named person to signed work. The difference is not the bar on the schedule. It is who can still be moved, and by whom.

Vendors use different labels for the same two states, which causes confusion when teams switch tools or compare vendors:

In Birdview, the difference between soft and hard allocation also reflects ownership: project managers place soft allocations to signal intent, and resource managers set hard allocations once the work is confirmed. The resource matching workflow follows the same path, from role placeholders to soft holds on named people to hard bookings at signature.

Do tentative bookings use up capacity?

It depends on the tool, and the answer decides when you see a conflict. Some tools treat tentative work as an overlay that never consumes availability. Others count it against capacity by default. Neither is wrong, but each hides a different risk.

In the overlay model, Resource Guru states that tentative bookings do not take up availability, so overriding one with a confirmed booking causes no clash; the clash check runs only when the tentative booking itself is confirmed. That keeps the schedule clean, but it pushes every conflict to the moment the client signs, which is the worst time to discover one.

In the reserve model, the pressure shows up early. Runn’s role forecast report includes tentative project workload unless you switch it off. The cost is that a person carrying three 30% holds looks fully booked even though, statistically, most of that work will not arrive.

Birdview combines both. Per Birdview’s help article on managing allocations, a soft allocation adds the person to the project team but does not consume capacity, so they stay allocable to other projects until a resource manager decides. At the same time, the Planning screen includes soft allocations in workload calculations by default, and one toggle switches the view to hard allocations only. You get both readings of the same schedule: “who is committed” and “who is under pressure if pipeline lands.”

A practical policy: use reserve-style behavior for scarce skills (a solution architect, a certified integrator) where a late conflict is expensive. Use overlay or unnamed role placeholders for the long tail of roles you can backfill quickly.

Which pipeline deals should get a named tentative booking?

Weight pipeline by win probability to forecast demand by role, but only give a named hold to deals above a threshold you set from your own conversion history. The six rules below are a starting policy. The numbers are illustrative placeholders, not industry benchmarks, and should be replaced with your firm’s own data after one quarter.

1. Weight hours by stage for role-level forecasts. Multiply expected hours by the stage’s win probability to size hiring and bench needs. Predictive resource forecasting works at this level, by role and by month. Pull stage probabilities from the last 12 to 24 months of closed deals, not from what sales hopes.
2. Name people only above a threshold. Below it, demand stays on an unnamed role. A common starting point is 50% or a verbal award. Teams running a 30/60/90-day capacity forecast often set a higher bar, around 75%, for the 60-day horizon.
3. Cap tentative load per person. Set a planning limit for confirmed work plus high-probability holds, based on each person’s available capacity. Keep a buffer for unexpected work and absences. Any scenario exceeding available capacity should trigger a staffing review, not become the default plan.
4. Give every hold an owner and an expiry. Tie the expiry to proposal validity or a fixed window, for example 30 days. Review expiring holds in the weekly resourcing meeting and either extend with a reason or release.
5. Change the hold when the deal stage changes. A deal that drops a stage loses its named hold that week, not at month end. Stale holds are the most common reason a soft allocation report stops being trusted.
6. Calibrate every quarter. Compare predicted and actual conversion by stage and deal size, then adjust thresholds. Split the check by deal size, because one blended rate can hide a stage where large deals stall.

Rule 2 matters most for the sales conversation. When sales asks “can we start on the 1st?”, the answer comes from named holds and confirmed load, not from a weighted forecast.

Why probability-weighted demand is not a staffing plan

A probability-weighted load is an average of outcomes that will never happen as an average. You can forecast with expected hours, but you cannot staff a person to them. This example shows why, using illustrative numbers.

Assumptions: one senior engineer, 40 hours per week of capacity, 24 hours per week already confirmed. Two deals are in the pipeline. Deal A needs 20 hours per week and is 60% likely to close. Deal B needs 20 hours per week and is 30% likely. The deals are independent.

The weighted load is 24 + (0.6 × 20) + (0.3 × 20) = 42 hours, or 105% of capacity. That looks like a small stretch someone could absorb with a bit of overtime. The actual outcomes look very different:

The expected value still comes out at 42 hours (0.28 × 24 + 0.42 × 44 + 0.12 × 44 + 0.18 × 64). But the weekly reality is either an underused engineer or an overloaded one. There is a 72% chance this person ends up over capacity, and an 18% chance they land at 160%.

Applying the rules changes the plan:

• Deal A clears a 50% threshold, so it earns a named hold. Confirmed plus held load would be 44 hours, which breaks the 100% cap for a scarce specialist. Put 16 hours per week on this engineer and the remaining 4 hours on a second person or an unnamed role.
• Deal B sits below the threshold, so it stays on an unnamed senior engineer role. It still appears in the role-level forecast at 6 weighted hours.

This is the gap that general resource overbooking prevention habits, such as planning to true capacity and keeping buffers, do not cover on their own. Overbooking against pipeline happens in the step where a forecast number is quietly treated as a booking.

How to convert tentative bookings into confirmed bookings

Check the person’s confirmed load before flipping soft to hard, then resolve any conflict in a fixed order agreed before the deal closed. Conversion day is when overlay-style holds turn into real clashes, so the rules need to exist before anyone is under pressure from a client.

1. Convert in priority order, not first-come. Agree the tiebreaker in advance: contract start date, client tier, margin, or strategic value. Without it, the account manager who calls the resource manager first wins, and that is rarely the best outcome for the firm. The same priority logic that settles conflicts between active projects should apply to conversions too.
2. Check load against confirmed work only. Before approving, look at the person’s workload with tentative holds removed and the new hours added. If the result breaks the cap, the conversion needs a decision, not just a click.
3. Work the options from cheapest to most expensive:
   • shift the start date within what the client will accept
   • swap in a person with equivalent skills, found through a skills matrix
   • split the work across two people
   • phase the hours so the peak drops
   • bring in a subcontractor
   • reopen the start date with the client
   • move a lower-priority confirmed booking, only with its project manager’s agreement
4. Tell the affected people. The booked person, the project managers on both sides of any swap, and the account manager should hear the decision the same day. Record why it was made.
5. Log the outcome. Which deals converted, when, and at what size feeds the quarterly calibration in the rules above.

Who can make the conversion matters as much as the order. In Birdview, a project manager can place a soft allocation, but turning it into a hard allocation needs a user with the “Manage hard allocations” permission. When the PM submits a resource request instead, the soft allocation sits as “Waiting for approval” until the approver accepts it, at which point it becomes hard. A rejected request leaves the allocation soft. The full resource request and allocation workflow describes how PMs and resource managers split that work.

Soft and hard allocations in Birdview PSA

Birdview handles tentative and confirmed bookings as soft and hard allocations on the Planning screen, with role placeholders for demand that has no named person yet. Each piece maps to one of the rules above.

On the Planning screen, soft allocations, hard allocations, and unnamed resource allocations appear as differently colored bars, each showing the allocation percentage and total hours. Allocations follow the company schedule and each person’s weekly schedule, and public holidays are excluded from available hours. That matters for the cap in rule 3: a 100% ceiling in a week with a holiday is a lower number of hours than in a normal week.

The workflow fits the 30/60/90 view many firms already use: hard allocations for the next 30 days, a mix of hard and above-threshold soft holds for 60, and unnamed roles for 90. Birdview’s resource planning software brings those three horizons onto one screen, so the resource manager does not rebuild them in a spreadsheet each Monday.

Plan pipeline as scenarios, staff it as commitments

Tentative bookings prevent overbooking only when they come with rules: fewer named holds, a cap per person, an expiry on every hold, and a conversion order agreed in advance. Forecast with weighted hours, staff with confirmed ones, and keep the two views side by side. To see soft and hard allocations on your own pipeline, book a Birdview demo and bring two live deals.

FAQ

What is the difference between soft and hard booking? A soft booking is a provisional hold on a person or role for work that is not yet signed, and the person usually stays available to other projects. A hard booking is a confirmed commitment to contracted work that uses up the person’s capacity. In Birdview these are called soft and hard allocations.

Should tentative bookings count toward capacity? Count them for scarce skills, where discovering a conflict at signature is expensive, and keep them as an overlay for roles you can backfill. The safest setup shows both views: workload including tentative holds, to see pressure building, and workload with confirmed work only, to see what is actually committed this month.

How do you weight pipeline when planning resources? Multiply each opportunity’s expected hours by its stage win probability, using conversion rates from your last 12 to 24 months of deals. Use the weighted total for role-level forecasts and hiring decisions. Do not book named people to weighted hours, because each deal either arrives in full or not at all.

What happens when a tentative booking is confirmed? The hold becomes a commitment and starts using the person’s capacity. Before converting, check their load against confirmed work only. If it breaks the cap, resolve it in a set order: move the start date, swap in an equivalent-skill person, split or phase the work, then use subcontractors.

How long should a tentative booking last? Link each hold to the proposal’s validity date or a fixed window, often 30 days, and give it an owner. Review expiring holds weekly. A hold with no expiry turns into a phantom booking that makes people look busy and pushes real work to someone less suited.