A PTO, shift swap and availability app your team will actually use

Every manager of an hourly team knows the Sunday night text: "Can anyone cover my Tuesday close?" Then come the replies, the side conversations, the swap that two people agreed on and nobody told the manager about, and the Tuesday when nobody shows up because everyone thought someone else had it. Time off works the same way. A request is scribbled on a paper calendar in the break room, or sent as a text, or mentioned in passing, and three weeks later two people on the same small crew are both off on the same Saturday.

A PTO, shift swap and availability app fixes this by giving every change to the schedule one front door. This guide covers what the current way costs you, exactly what the app should contain, a worked request you can hand to FORGE, how to roll it out, and how to tell whether it is working.

What the current way costs you

Most teams run time off and shift changes through some mix of group texts, a paper calendar, a shared spreadsheet and the manager's memory. Each one breaks in a predictable way.

• Group texts lose decisions. A swap agreed in a thread of forty messages is invisible to the person building next week's schedule. Nobody can search it later when there is a dispute.
• Paper calendars live in one place. The night manager cannot see the request pinned in the day manager's office, and the calendar cannot warn anyone that a day is already short.
• Spreadsheets have no rules. Anyone with access can type over anyone else. There is no approval step, no notification, and no history of who changed what.
• The manager becomes the bottleneck. Every request lands on one phone. When that person is off, decisions stop, or worse, get made without them.
• Fairness becomes a feeling. Without a record, people believe the same few always get the holidays. Sometimes they are right, and nobody can prove it either way.
• Rigid scheduling software can be its own problem. Large workforce systems are built for large companies. Smaller teams often pay for features they never use while the one rule that matters to them, such as "two certified openers on every Saturday," is hard to set up.

The cost shows up as short shifts, overtime nobody planned, managers spending evenings on their phones, and good people leaving because getting a day off felt like begging.

What the app should contain

Think of the app as four parts: requests, coverage, approvals and records. Here is what each part needs.

Roles

• Employee: submits time off requests, offers shifts, picks up open shifts, updates availability, sees their own balance and history.
• Shift lead or supervisor: sees the coverage calendar for their area, approves or declines swaps and requests for their crew within limits you set.
• Manager: approves anything outside the lead's limits, sees all locations or departments they run, sets blackout dates.
• HR or owner: manages balances and policies, sees reports across the company, and reviews the decision history.

Request types and fields

• Time off request: employee, type (vacation, sick, personal, unpaid, other types your policy uses), start and end date, full or partial day, hours, note, attachment if your policy asks for one.
• Shift swap: the original shift, the person offering it, the person taking it, and whether both have agreed.
• Open shift pickup: a shift posted by the manager or released by an employee, with who is qualified to take it.
• Availability: recurring days and hours each person can work, with an effective date, so a student's new semester hours or a parent's new school schedule is on record before the schedule is built.

Statuses

Use a short, clear status list and stick to it: Draft, Submitted, Waiting on the other employee (for swaps), Waiting on approval, Approved, Declined, Cancelled. Every status change records who made it and when.

Rules worth building in

• Coverage minimums: the fewest people, or the fewest people with a given skill, allowed on a shift. A request that would drop below the minimum is flagged before anyone approves it.
• Blackout dates: inventory days, peak season, events. Requests on those dates go straight to the manager with a note.
• Notice periods: how far ahead a request must come in. Late requests are allowed but marked.
• Qualification matching: only people trained for a role can pick up or swap into it.
• Overtime warnings: a pickup that would push someone past the hours you set is flagged for the manager.

Screens

1. My requests: a phone-first screen with a big "Request time off" button, an "Offer a shift" button, the person's balance and the status of everything they have asked for.
2. Open shifts board: shifts anyone qualified can claim, newest first.
3. Coverage calendar: the manager's main view. Each day shows who is scheduled, who is off, who is pending, and a color when coverage falls below the minimum.
4. Approval queue: everything waiting on this manager, oldest first, with the coverage impact shown next to each request.
5. Balances: each person's starting balance, used, pending and remaining.
6. History and reports: every decision, filterable by person, date and type.

Notifications

• The employee hears back the moment a request is approved or declined, with the reason.
• The swap partner is asked to accept or decline.
• The manager gets a daily summary of pending requests, plus an immediate alert when a request lands on a short day or a blackout date.
• Everyone on a shift is told when a swap changes who they are working with.

Reports

• Requests by month and by type.
• Average time from request to decision.
• Days that fell below coverage, and why.
• Holiday and weekend time off by person, so fairness becomes a fact you can show.

Example request

Here is the kind of request you could hand to FORGE, written in plain words. Adjust the details to your own team.

Example request: "Build a time off and shift swap app for our three locations. Employees should be able to request time off from their phone, choosing vacation, sick or personal, full or partial days. They can offer a shift they cannot work, and anyone at the same location trained for that role can claim it. Swaps need both people to agree, then go to the shift lead. Shift leads approve for their own location unless the request falls on a blackout date or would leave fewer than two people on the floor, or fewer than one certified opener on a morning shift. Those go to the location manager. Show a monthly coverage calendar for managers with red days when coverage is short. Track vacation balances: each person starts with the hours I upload from a spreadsheet, approved requests subtract, pending requests show separately. Employees can set their weekly availability with a start date. Send a notification for every decision and a daily summary to managers at 7 a.m. Keep a record of every approval and decline with who made it and why. HR sees everything across all three locations."

That request names the roles, the rules, the screens, the notifications and the data you are starting from. It is the level of detail that gets you a tool your team can use on day one.

How the current tools compare

Rollout plan for your team

A good app with a bad rollout ends up ignored. Follow these steps.

1. Write down your rules first. Coverage minimums, blackout dates, notice periods, who approves what and how balances work. If two managers handle requests differently today, settle it now. The app will make your policy visible, so make sure it is the policy you mean.
2. Gather your starting data. A list of employees with their location, role, qualifications and current balance. A spreadsheet is fine.
3. Build and test with one manager. Have the manager submit fake requests from a phone, approve some, decline some, and try to break the coverage rules.
4. Pilot at one location for two weeks. Pick the location with the most requests or the most friction. Tell the crew the date the app becomes the only way to ask.
5. Show people in person. Five minutes at a shift meeting beats any email. Have everyone submit their availability on the spot so the first thing they do in the app is useful.
6. Close the old doors. After the rollout date, a request by text gets a friendly reply: "Please put that in the app so it is on record." This is the step most teams skip, and it is the one that decides whether the app sticks.
7. Review after two weeks. Ask leads what slowed them down. Adjust the rules, add a missing request type, change a notification time.
8. Roll out to the next location with the pilot manager helping.

Mistakes to avoid

• Building the schedule and the change workflow at once. If your schedule already lives somewhere that works, leave it and fix the changes first. You can bring the schedule in later.
• Too many statuses. If people cannot tell what "Pending review level two" means, they will text the manager to ask.
• Letting the app approve things automatically that should be judged. Automatic approval is fine for a swap between two qualified people on a fully covered day. It is not fine for the week before a holiday.
• Hiding the reason for a decline. A decline with no reason starts a hallway conversation. Make the reason required.
• Forgetting the night and weekend crew. Test the app with the people who never come to the office.
• Treating balances as a guess. If payroll keeps the official balance, reconcile on a set schedule so the app and payroll never drift apart.

How to measure that it works

Pick a few numbers and check them monthly.

• Short shifts: days that ran below your coverage minimum. This should drop.
• Time to decision: how long requests wait for an answer. Aim for same day or next day.
• Requests outside the app: count the texts and verbal requests managers still receive. This should trend to zero.
• Unplanned overtime hours caused by last minute gaps.
• Manager time: ask managers how many evenings they spent sorting coverage before and after.
• Fairness: compare holiday and weekend time off across people over a quarter.

Checklist before you build

1. List every type of time off your policy allows.
2. Write each coverage minimum by location, shift and role.
3. Decide who approves swaps, pickups and time off, and the limits for each.
4. List your blackout dates for the next six months.
5. Decide your notice period and what happens to late requests.
6. Collect the employee list with roles, qualifications and balances.
7. Decide which notifications go to whom, and when.
8. Choose the pilot location and the rollout date.
9. Confirm your time off, overtime and scheduling rules with your HR advisor or the relevant labor authority where your people work.

How FORGE handles it

With FORGE, the manager who knows the rules describes the app in plain words, like the example request above. A panel of top AI models plans the tool, a dedicated AI crew builds it, and every piece is checked for quality and security before it is saved. Most teams have their first real tool the same day, and it works on a phone, a tablet or a desktop.

The app lives inside your company and only the people you invite can get in. Owners and admins manage the workspace, builders make and change tools, and app users, the crew requesting time off, are free. Every decision and every change to the app is recorded with who did it. When your rules change, such as a new blackout week or a new coverage minimum, the builder describes the change, and a change costs a small fraction of a build and only counts when something actually changes.

It is $49 a seat a month for each person who builds, with 3 builds included. Our team starts every company with a workflow workshop, so your first tool is the one costing you the most time. If that is the Sunday night coverage scramble, talk to us.

Questions people ask