7 Leave-Planning Mistakes the Optimizer Won't Fix for You

What the optimizer knows — and what it cannot know

The tool takes five inputs: a country, a number of leave days from 1 to 30, a weekend pattern of Saturday-Sunday or Friday-Saturday, one of three strategies, and company days added by clicking working days on the calendar. That is the whole of what it knows. Everything in the table below is outside that list, which is why every mistake here passes through the tool unchallenged.

Keep that boundary in mind for the rest of this guide. A plan the optimizer produces is a suggested arrangement of dates, not an approved request. The final check always happens against rules the tool has never seen.

Mistake 1: Assuming company rules do not matter

What goes wrong

A bridge can be perfect on the calendar and impossible under company policy. Leave may expire at a fixed date, so days saved for a December bridge may already be gone. A request may need a minimum notice period, so a bridge found a week before departure may be too late to file. And blackout dates — periods when no leave is approved, however the calendar looks — can sit exactly on the bridge the optimizer recommends. None of these appear in the tool, because none of them is a date fact: they are employer rules, and they differ from one company to the next.

Why the tool cannot catch it

The tool has no field for policy. Its inputs are country, leave days, weekend pattern, strategy, and company days. There is nowhere to enter an expiry date, a notice period, or a blackout window, so the optimizer treats every working gap in 2027 as equally bookable. A gap that your employer has closed looks exactly like a gap that is open.

Do this instead

Before running the optimizer, confirm three things with your employer: the last date your current leave balance can be used, how far in advance a request must be filed, and whether any blackout periods cover the breaks you are considering. Then run the tool with those constraints in mind, and treat any recommended break that falls inside a blackout window or past an expiry date as unavailable, however good its ratio looks.

Mistake 2: Counting public holidays as leave days

What goes wrong

A public holiday is already a day off. It costs no leave, and the optimizer never charges leave for it: its non-working set is public holidays plus company days plus weekends, and leave is spent only on the working gaps between those runs. The mistake is to plan as if the holiday also consumed a leave day — counting a 12-day break as 12 leave days, for example, when the tool correctly charges only the working days inside it. Double counting inflates the apparent cost of every break, makes good bridges look unaffordable, and can push a planner toward a worse break or toward saving leave that was never needed.

Why the tool cannot catch it

The tool reports leave used and days off as separate numbers, and it cannot know which number the planner is carrying in their head. It also enforces the distinction on its own side: public holidays and weekend days cannot be clicked as company days, so the tool never lets a holiday be entered twice. But a planner working from a mental total, a spreadsheet, or a conversation with a manager can still double count, and the tool output will not flag it because the output itself is correct.

Do this instead

Always read the two numbers separately: days off is the length of the break, leave used is what the break costs. When you tell a manager or a partner how much leave a trip needs, quote the leave-used figure, not the break length. And when you reconcile against your balance, subtract leave used only — the holidays inside the break were never yours to spend.

Mistake 3: Letting a break cross the leave-year boundary unexamined

What goes wrong

A leave year is not necessarily a calendar year. Many employers run the leave year from April, from the hiring anniversary, or from some other start date, so a break that straddles the boundary draws its days from two different annual balances. A planner who assumes every day in a December-to-January break comes from the same balance can end up short in one year and overdrawn in the other, or can discover that days they expected to carry over have expired at the boundary instead.

Why the tool cannot catch it

The tool data covers 2027 only, and it has no concept of a leave year at all. It cannot assign a leave day to one annual balance or another, and this guide makes no claim about how the tool behaves for dates outside 2027, because that behaviour is not covered by the verified facts for this tool. Any rule about which year a straddling break belongs to lives in the employer policy, not in the calendar.

Do this instead

Find your leave-year start and end dates before planning any break near a boundary. Ask which annual balance each day of the break will be charged to, and whether unused days carry over the boundary or expire there. Then check the break against both balances, not just the total number of days you hold.

Mistake 4: Using a full-time balance when you work part-time

What goes wrong

Part-time leave balances are normally scaled in proportion to hours worked. A planner who enters the full-time allowance into the tool — or who copies a full-time colleague plan — will see breaks the part-time balance cannot pay for. The plan looks affordable because the input was wrong, not because the arithmetic failed. The shortfall usually surfaces at the approval stage, when the request exceeds the balance actually held, and by then the preferred dates may be gone.

Why the tool cannot catch it

The tool accepts a single number of leave days. It does not ask whether the planner works full-time or part-time, and it has no way to scale an allowance by contracted hours. Whatever number is entered is treated as the budget, and every strategy optimises against it faithfully. A wrong budget produces a faithfully wrong plan.

Do this instead

Work out the part-time balance first, in proportion to contracted hours, and enter that number — not the full-time figure. If the proportion is not a whole number, enter the lower whole number: a plan built on a day that does not exist will fail at submission, while a plan built on one day less can still be extended if the balance allows.

Mistake 5: Planning shift work on a weekend model

What goes wrong

The optimizer assumes a fixed weekend: either Saturday-Sunday or Friday-Saturday, the same every week of the year. Shift and rotating-roster work does not follow that pattern. Rest days rotate, weekends on duty are normal, and the days that feel like a weekend change from week to week. A bridge built on the assumption that Saturdays and Sundays are always off will recommend leave on days a shift worker is already resting, and will miss the real gaps — the working days that sit between rostered rest days and public holidays.

Why the tool cannot catch it

There is no roster input. The weekend setting offers exactly two patterns, and the non-working set is built from holidays, company days, and whichever of those two patterns is selected. A rotating roster cannot be expressed in those terms, so the tool plan answers a different question from the one a shift worker is asking: it answers what the bridges would be for a fixed-weekend worker in the same country.

Do this instead

If you work shifts, do not submit a tool plan unchanged. Use the tool only to spot where public holidays fall, then rebuild the plan against your actual roster: mark your real rest days, find the working days between rest days and holidays, and count leave against those days. Where the roster is not yet published for the dates you want, wait for it rather than booking on a weekend assumption that your roster will not honour.

Mistake 6: Forgetting school holidays

What goes wrong

For a household with school-age children, the useful question is often not which bridge is longest, but which break lines up with the school holidays. A parent who books the highest-ratio bridge in a term-time week gains days off and loses the point of them: the children are in school, childcare still has to be arranged, and the family trip the leave was meant for cannot happen. Conversely, a slightly less efficient bridge inside a school holiday can be worth far more than a longer break at the wrong time of year.

Why the tool cannot catch it

The tool data holds national public holidays only — 118 days across 10 countries for 2027. It contains no school-holiday layer, no school-term dates, and no input where school dates could be added as a category. School holidays vary by region and by school, so they could not be carried in a national set in any case. The optimizer is therefore blind to the calendar that matters most to a family planner, and its highest-ratio recommendation may fall in exactly the wrong week.

Do this instead

Get the school calendar first, then overlay it on the tool output by hand. Keep the tool for what it does well — finding bridges around public holidays — and judge its recommendations against the school dates: a break that overlaps a school holiday outranks a longer break that does not, whatever the ratios say. Where school dates are not yet published for the term you want, treat the tool plan as provisional until they are.

Mistake 7: Treating the all-opportunities table as a plan

What goes wrong

The all-opportunities view is the easiest output to misread, because it looks like a menu of plans. It is not a plan at all: it is every bridge candidate in the year, ranked by ratio, and it is not filtered by the leave budget entered. Rows that cost more leave than the budget appear alongside rows that fit. A planner who works down the table booking each row will overspend the budget, request days they do not hold, and have the later requests refused — while the earlier, affordable rows may already have been displaced by the unaffordable ones.

Why the tool cannot catch it

The table is doing exactly what it is designed to do: listing all candidates for comparison. Filtering it by budget would destroy its purpose, which is to show the highest-ratio breaks in the year, including ones a different budget might unlock. The tool cannot warn that a row exceeds the budget without changing the view into something else, so the responsibility for reading the Leave used column sits with the planner.

Do this instead

Pick a strategy first, then choose within budget. Use the longest strategy for one break, or the balanced strategy for a spread of breaks, and let the tool enforce the budget for you. Use the all-opportunities table only to compare candidates, checking the Leave used figure on every row before treating it as bookable. The example below shows the trap on a single input:

The 16-day row is longer and looks better, but it costs 7 leave days against a 4-day budget. Booking both rows together would cost 11 leave days for two overlapping breaks — a double failure, since the breaks overlap each other as well as the budget. The table rewards careful reading, not enthusiastic booking.

Before you submit: one final check

1. Confirm the balance you entered is the balance you actually hold, scaled for part-time hours if that applies.
2. Confirm no recommended day falls inside a blackout period, past an expiry date, or before a notice deadline.
3. Confirm each break is charged to the correct leave year, and that school dates and rostered rest days have been overlaid where they apply.
4. Confirm every row taken from the all-opportunities table fits the budget on its own, and that chosen breaks do not overlap each other.
5. Re-read the leave-used figure, not the days-off figure, when you state how much leave a trip needs.

The optimizer output is a suggested arrangement of dates, computed exactly from the inputs given. Before submitting it, run it once against company policy: the tool cannot approve a request, and a plan that survives that check is the one worth filing. One coverage note for planners looking beyond these 10 countries: mainland China 2027 holiday data is not in version 1 of the tool, pending publication of the State Council 2027 holiday schedule, so plans around mainland China holidays cannot be built with this tool yet.