Features · Shiftly
An open shift needs more than an empty calendar cell. Shiftly's feature story is about the facts that make someone a reasonable candidate, the difference between a suggestion and coverage, and the next decision when a shift falls through. Reused primitives do not make the early-access roster surface a finished product.
Reused vs early access
The matching primitives underneath shiftly -- availability, eligibility, the credential-gate, and self-healing reassignment -- are the same primitives schedule.software already describes running in production for crew dispatch, re-skinned for a staff shift. The shift-roster board and the K-12 sub-coverage skin sitting on top are new surface, marked early access, not claimed live.
Reused & shipped elsewhere
Checking a person's own stated availability window against a shift's time window is the same primitive already running in production for crew scheduling elsewhere in the fleet. Shiftly re-skins it for a staff shift instead of a crew assignment.
Reused & shipped elsewhere
A shift that requires a credential checks the assignee's credential expiry and scope against the shift's requirement before the assignment is offered -- the same hard-constraint gate schedule.software already describes running on live crew-dispatch assignments (expiry must exceed the scheduled date, scope must match).
Reused & shipped elsewhere
Role and eligibility rules narrow the candidate pool before availability is even checked, so a shift is only ever offered to someone actually allowed to work it.
Reused & shipped elsewhere
When a covered shift falls through, a ranked, minimal-cascade replacement proposal is generated for that one shift -- the same self-heal mechanism schedule.software describes running against real crew-dispatch schedules, applied here to a roster callout instead of a route change.
Early access
The visual board a manager posts, reviews, and covers shifts from is new surface being built on top of the reused primitives above. It is not live today.
Early access
The substitute-specific skin over the same shift/eligibility/credential mechanism -- building assignment, substitute-credential requirement, sub-pool matching -- is new surface being built. Not live today.
The availability input is a person's stated window and the window required by the shift. The outcome should explain fit, not infer willingness from an empty space. Someone who is free later in the day is not therefore available for the first part of the shift. Start an evaluation with the exact interval you need covered, including the date, rather than a loose label such as morning. This gives the review a clear question to answer.
Availability data also has an owner. A stale window can produce a plausible suggestion that the person immediately declines. Discuss who maintains that information and how your team would notice a change; do not assume a two-way calendar connector from the existence of a scheduling rule. If calendar synchronization is a requirement, ask for its current status in your intended deployment. This page neither connects a calendar nor reads anyone's availability.
Role eligibility narrows the candidate pool. A credential requirement then asks whether the supplied record covers the shift's date and scope. Keep those questions separate during review: being a member of the team is not the same as meeting a particular credential requirement. The value of the gate is that a convenient name does not replace the stated requirement. If the record is wrong, correct the record through the appropriate operational process before interpreting another proposal.
The boundary matters to both buyer and staff member. Shiftly does not certify, license, issue or authenticate a credential. A stored expiry date is a fact supplied by the organization, not evidence that the issuing authority has confirmed it to this product. Ask which records are needed for a walkthrough and use a synthetic current/expired example first. Do not email credential scans or sensitive personnel files to explain a matching question.
The self-heal mechanism described on the site proposes ranked replacements for an affected shift with limited knock-on changes. Ranking helps the manager see options; it does not eliminate operational judgment. A manager may know a practical constraint that has not been represented. The useful next action is to identify that missing fact and discuss whether the surface can model it, rather than presenting a proposed order as an unquestionable answer.
An empty candidate set is a legitimate outcome. So is a proposal that needs a human decision before it can be used. Ask to walk through both. If the only demonstration you see is an easy match, you have not learned how the team will handle the day when all familiar replacements are unavailable. The feature should make the unresolved decision clearer, and the early-access review should identify anything it cannot yet express.
For a team evaluating Shiftly, the feature checklist should end in a small set of decisions: which shift will be described, which rule excludes the wrong candidate, how acceptance will be recognized and what a callout leaves for a manager to resolve. Ask for those outputs before comparing planned tiers. The published prices are display-only and the next step is a conversation. This page cannot provision a board or authorize a charge.
If your main requirement is a record of hours actually worked, this roster product is not the answer to that job. If your main requirement is a public appointment link, start with the family's appointment lane. Shiftly stays focused on scheduled coverage. Its surface guide identifies who acts at each stage; its privacy guide explains the adult scheduling facts worth bringing to a review.
Claim a hostname, verify it with the DNS-TXT record we hand you, and once it verifies the shift board serves from your own domain — included on every paid plan, not paywalled to a top tier. Full white-label branding (logo, colors, the badge gone) is the reseller tier. See Your brand, your domain on the home page for the full mechanism.
Two floors that never move, at any tier: the notification-email sending domain stays the platform’s (you set the display name and reply-to, not the From-address), and the consent/legal footer stays the platform’s.