Your Next Client Is Buying Hours You Already Promised
Before offering a delivery date, count the support, revisions and unfinished commitments existing clients still need from the same week.
On this page
The worked week and hour estimates are illustrative.
Picture next week. A prospective client wants a small build by Friday. You estimate eight hours, including checks and handoff, and look at a forty-hour working week. It seems possible, mostly because those forty hours haven't met your other clients yet.
Meanwhile, one existing client is waiting for a revision. Another has a delivery date on Thursday. You also owe support to clients whose systems may need attention during those same hours. None of that appears on the new proposal.
Each engagement can look manageable on its own. Before offering Friday, put the existing promises beside the new estimate and see which hours remain available.
Count promises that have not become tasks yet
Start with the work you already owe during the proposed delivery window. Include the remaining effort on agreed deliverables and the corrections still covered by a previous scope. A finished first draft can leave another round of work waiting for the client’s reply.
For a fractional leader, that might be a forecast review followed by changes to the board pack. For an automation consultant, it might be a routing change awaiting approval. A quiet client has not necessarily released the hours you expected to spend on them.
Keep uncertain work visible. Record when you expect a reply and what happens to the schedule if it arrives late. Avoid counting a pending revision as both booked delivery and part of a general support allowance.
Work through the week before quoting the date
Use the actual window you intend to promise. In the illustrative week below, ten hours go to calls and running the practice. Existing work takes another twenty. The consultant holds six hours for support and interruptions, based on a review of recent weeks.
| Time in the proposed delivery week | Hours |
|---|---|
| Working time available | 40 |
| Calls and practice overhead | −10 |
| Agreed client deliverables | −16 |
| Outstanding revisions and changes | −4 |
| Support and interruption allowance | −6 |
| Available for the new project | 4 |
The eight-hour build is four hours short of fitting. Offering Friday would depend on something moving or the support allowance going unused. Decide which assumption you are prepared to make before the date reaches the proposal.
For a longer project, repeat the check for each week. Spare time after the promised handoff cannot cover a shortage before it.
Give the support allowance a basis
Six hours is a planning assumption for this example. Look at what recent support actually required, including investigation and the follow-up after a fix. Consider whether the coming week contains a launch or another known reason for demand to change.
Keep a range when the history varies. If a quiet week needed two hours and a difficult week needed ten, a six-hour allowance still leaves a possible shortfall. Record how you will handle it. That may mean arranging backup with someone qualified and available, or offering a later delivery date.
A new practice may have little history to use. Mark the estimate as uncertain and leave more room while you learn. Revisit the allowance after each week rather than treating an arbitrary percentage as a service guarantee.
Check when the hours are needed
Four spare hours spread across ten gaps may be difficult to use for a build that needs sustained attention. Put the proposed work into real blocks and check those blocks against the availability you have promised other clients.
Read the support promise precisely. A commitment to acknowledge an issue is different from a commitment to restore service. If two clients can require your immediate attention at once, the weekly total does not resolve that collision. Establish coverage before adding another promise with the same response window.
Keep client dependencies beside the date. If access arrives on Wednesday instead of Monday, decide whether the handoff moves. Writing that assumption into the proposal gives both parties something concrete to revisit.
Leave one short note before sending the proposal
You can do this in the document where you prepare the scope. Fill in the note below, then offer a date that fits the remaining time. Include the new project’s review and handoff effort in its estimate.
Delivery window: [dates] Available hours after overhead: [hours] Existing delivery and revisions: [hours and commitments] Support allowance: [hours, basis and uncertainty] Time left for this project: [hours and usable blocks] New project estimate, including review and handoff: [hours] Date I can offer: [date and client dependencies] If support exceeds the allowance: [coverage or schedule decision]
If the work does not fit, change the proposal before sending it. A smaller first delivery or a later date may be enough. Hiring help only adds usable capacity once that person’s availability and responsibilities are agreed, with time allowed for briefing and review.
Sources reviewed
Reviewed November 1, 2026. The worked example and capacity check are editorial analysis, not a reported customer result.
- Planisware Q1 2026 revenue release, April 16: support revenue growth and allocation of support resources to initial implementations.
- Planisware Q3 2026 revenue release, October 23: support growth drivers, including reallocation of teams previously assigned to new implementations.
Set the date after counting the existing work
Before the next proposal, check the week in which you intend to deliver. Bring forward the obligations that have no calendar block yet. Leave the uncertain support estimate visible.
If the eight-hour build has only four hours available, offer a smaller delivery or find a later slot before you send the proposal.
Product screens show a sample workspace. Client names in examples are fictional.