Availability and time off

Two different things

Availability is a recurring weekly pattern: "I can work Tuesday to Friday, evenings only". It repeats until changed and is not approved by anybody — it is a statement of fact about someone's life.

Time off is a dated request for specific days: "the 14th to the 18th of August". It has a type, a status, and a manager decision.

Using the wrong one is the most common setup mistake. A student who cannot work Monday mornings all term needs availability. The same student going to a wedding needs a time-off request.

The three kinds of availability

Each entry covers a day of the week and a time range, and is one of:

• Available — can work this window.
• Unavailable — cannot. Scheduling into it raises a conflict.
• Preferred — can, and would like to. The agent favours these when it has a free choice, which is how you reward people for stating a real preference instead of gaming the system with a false "unavailable".

An entry can carry a validity window, so "unavailable Monday mornings until the end of term" expires by itself rather than being forgotten.

Employees who have been clocking in for a while can have their availability suggested from their actual punch history — the hours they really work, offered as a starting point they confirm. It is far more accurate than what most people would type from memory, and it is one tap on mobile.

Time-off requests

Employees request from the web app, their phone, or by asking the assistant. Seven types are available — vacation, sick, personal, unpaid, parental, bereavement, other — and a request moves through pending, then approved, denied or cancelled.

Managers see pending requests on the dashboard and can decide them individually or in bulk, which matters when a public holiday produces fifteen requests in one evening. Managers can also enter time off on somebody's behalf, for the phone call that came in at 6am.

Approved is the state that changes scheduling. Scheduling over approved time off raises a conflict, the publish pre-flight reports it, and the agent will not draft into it. A pending request does none of that — so decide requests before you build the week, not after.

How it all feeds the schedule

Both feed the same context the agent reads before it drafts, and both feed the conflict check that runs when a shift is saved by hand.

That is the argument for putting patterns in the system rather than in a prompt or a manager's head: stated once, they are honoured every week by the AI, by the conflict checker and by the publish pre-flight, without anybody remembering to mention them.

Recurring hard limits — maximum weekly hours, minimum rest between shifts — belong in compliance rules rather than in availability, because those are policy about everyone rather than facts about one person.