August 11, 2026
At 8 or 10 people, PTO tracking barely needs a system. Someone messages the founder or office manager, that person remembers who's out and when, and the whole team's schedule lives comfortably in one person's head. It's not a process, but it works, because the team is small enough that one person really can hold all of it. The problem is that this setup doesn't degrade gracefully. It works fine, then it works fine, then one week it very much doesn't -- usually right when two people from the same small team both get approved for vacation during your busiest stretch of the quarter. Nothing about the *system* changed. The team just grew past the point where memory is a reliable source of truth.
Here's what it actually looks like. A manager gets a Slack DM: "Hey, can I take the week of the 14th off?" They glance at their own memory of the team's schedule, don't recall a conflict, and reply "sure, sounds good." That's the entire approval. No record, no cross-check, just a thumbs-up emoji buried in a DM thread. What the manager didn't check -- because there was nowhere to check it -- is that someone else on the same three-person team already had that exact week approved off, via a completely different channel, two weeks earlier. Maybe it was an email. Maybe it was a note scribbled on a shared calendar that the manager doesn't check daily. Either way, the conflict doesn't surface until someone notices the schedule looks thin, usually a few days before the week in question, when it's too late to easily ask anyone to change plans. This isn't a one-off mistake by a careless manager. It's the predictable output of a system where approvals are messages instead of records, and where there's no single place that reflects who's actually off on any given day.
The scheduling collision above is the headline failure, but it's really a symptom of four underlying gaps: **No single source of truth.** Email, Slack, and a shared calendar are three different places that might each have a partial, possibly outdated picture of who's approved off. None of them is authoritative, so nobody -- not even the manager -- can say with confidence "here's exactly who's out next week" without manually reconciling all three. **No real-time balance visibility.** An employee requests three days off with no idea whether they actually have three days left. A manager approves it the same way. Balances live in someone's mental model or a spreadsheet that's updated whenever someone remembers to open it, which means approvals routinely happen disconnected from whether the time is even available. **No auditable approval record.** When someone says "but you told me it was fine" and the manager doesn't remember it that way, the resolution is scrolling through old DMs and email threads trying to reconstruct what was actually agreed to. That's a bad use of anyone's time, and it's exactly the kind of dispute that a real approval workflow is designed to avoid -- an approval should be a state change with a timestamp, not a conversational vibe. **No team-level view.** Even a diligent manager is stuck mentally cross-referencing a series of individual requests instead of looking at one calendar that already shows everyone's approved time off. That cross-referencing is exactly the step that gets skipped under time pressure -- which is how the Slack-approval collision happens in the first place.
The fix isn't a heavier process bolted onto email and Slack -- it's replacing the request/approval step entirely with something that behaves like actual infrastructure instead of a conversation. Three things matter here, and they're the core of how a PTO tool built on ViibeStack should work for a team this size: A real, running balance per employee, calculated from your actual accrual policy -- not a generic "15 days a year" default that doesn't match how your business actually grants time off. If your accrual is different for hourly versus salaried staff, or vacation accrues monthly while sick time is front-loaded annually, the balance should reflect that automatically, so a request can be checked against real numbers instead of someone's guess. A request/approval flow that's a genuine state change -- submitted, pending, approved, denied -- attached to a record, not a message that can get lost in a scroll or forgotten in a DM. Approving something should mean it's now true everywhere, not true in one person's memory. A shared calendar view so a manager can see the whole team's approved time off before approving anything new, not after. That one screen is what would have caught the scheduling collision above in about two seconds, instead of a few days before it became unfixable. This is a smaller, more specific problem than what most general HR platforms are built to solve, which is worth keeping in mind if you're weighing buying a full HR suite versus building something scoped to your actual process. A 30-person company usually doesn't need multi-country compliance logic or a benefits module -- it needs the four things above, done well.
Before scoping a tool, get three things settled on paper, because these decisions shape every screen and rule that comes after: 1. **Your actual accrual rules.** How much time do people earn, on what schedule, and does it differ by role or employment type? Write down the real policy, not the rounded-off version people say out loud. 2. **Who approves for which team.** Is it always the direct manager, or does it route differently for certain roles? If your team structure is a bit tangled, it's worth thinking through this the same way you'd think through role-based permissions for any other internal tool -- decide who has visibility and approval rights before you build the screens. 3. **Whether time-off types need different rules.** Does sick time require different documentation or looser advance notice than vacation? Does it accrue differently? Decide this now, not mid-build. And just as important, know what a first version doesn't need. Skip multi-country compliance rules, skip payroll integration, and skip tenure-based accrual tiers for now -- none of that is required to fix the actual problem, which is that approvals need to be records instead of messages, and a manager needs one place to see the whole team before saying yes. Get those three decisions written down and you've got something buildable this week, not a six-month HR platform project.