Contact · Shiftly

Bring one shift that is difficult to cover.

Write to [email protected]. A short description of the scheduling problem is enough to begin. This is an email contact page, with no intake form, booking action, account creation or checkout. Your email application handles the message when you choose to send it.

Tell us which decision stalls

Some teams spend their time describing open shifts. Others know the requirement but cannot find a suitable person quickly. Others have a list of plausible people and cannot tell who has actually agreed. Say which of those resembles your day. Include an approximate number of locations or recurring shift types if it helps, but leave out names and personal contact lists. A rough scale and a precise difficulty are more useful than a complete staff export.

For a callout example, describe the original requirement, the changed circumstance in general terms and the decision you could not finish. There is no need to explain a staff member's health or personal situation. Say that the assigned person became unavailable. If you want to discuss the substitute-coverage skin, describe the adult role, building condition and credential requirement, with no student schedule or classroom roster attached.

Choose the enquiry scenario that matches the answer you need

For a product-fit enquiry, describe one synthetic adult shift, the action currently handled by messages or calls and the specific decision you want a roster surface to make clearer. State whether the difficulty is expressing the requirement, finding eligible people, presenting a proposal, collecting a response or repairing coverage after a callout. A reply can then address the relevant boundary instead of returning a catalogue of unrelated capabilities.

For an exclusion enquiry, provide the fictional shift window, role and location plus the candidate condition you expected to pass. Say whether the apparent mismatch concerns availability, eligibility or a supplied credential date or scope. Do not ask the marketing page to decide whether a real document is authentic. The useful output is an explanation of which comparison the product can represent, what reason should be visible and which fact remains owned by an issuing authority or manager.

For an uncovered-result enquiry, explain that no eligible option remained and name the next adult decision in your present procedure. The desired behaviour may be a visible unresolved state, a wider search requiring approval or a direct assignment made by a manager. Asking this way prevents an empty candidate list from being treated as a defect that should be hidden with an ineligible suggestion.

Format the example so a reply can separate input, output and refusal

Use a short block with headings: Requirement, Candidate facts, Expected result, Observed question and Required next action. Under Requirement, include the full window, role and location. Under Candidate facts, use invented labels and only the availability or credential attributes relevant to matching. Under Expected result, say proposed, excluded or unresolved. Under Observed question, identify the difference you need explained. This format is readable without screenshots and discourages accidental disclosure.

If the question concerns a response, state whether the adult was merely proposed, was asked, declined, accepted or has not replied. If it concerns a later callout, state that the prior assignment became unavailable and omit personal reasons. If it concerns operator scope, describe the organisational relationship between the requester, team and location without naming employees. These distinctions determine whether the question concerns matching, communication, authority or visibility.

Do not attach passwords, session links, credential documents, staff directories, personal addresses, private messages or records from another system. An email address is not a secure upload workflow. If an agreed evaluation later requires operational material, the responsible parties need to establish the transfer route, permitted viewers, purpose, retention and deletion steps before sending it.

Expect a bounded response, not an implied service commitment

A useful product response should restate the scenario, identify the matching or workflow boundary involved, and distinguish reused scheduling rules from the early-access Shiftly surface. It should name any unsupported integration, permission or deployment requirement. It should also say whether the question can be explored with synthetic inputs now or needs to wait until a particular screen can be demonstrated.

The response cannot authenticate a credential, accept a shift for an adult, alter a live roster, provision an account, guarantee coverage or establish a support deadline. It should not describe deterministic constraints as AI. It should not turn published planned pricing into an invoice or subscription offer. Those refusals keep the enquiry useful by showing which decisions remain with the organisation.

Email delivery and timing remain outside the renderer. The mail link opens the visitor's email application; this site does not claim that a message arrived, that a mailbox is continuously staffed or that an answer will come within a promised window. If the issue concerns immediate operating coverage, use the organisation's current escalation route. The early-access address is for evaluating product fit and clarifying a future workflow.

Bring a small roster with a real decision in it

Choose a recurring coverage problem you can describe without sending personnel records. A useful example has one location, a shift window, a required role and the condition that usually makes replacement difficult. Say whether your present process loses time finding people, checking requirements or discovering that a suggestion was never accepted. These are different failures. A long list of requested features can hide the one decision that actually delays the morning.

Use neutral labels such as Person A and Person B. Describe that a credential is current or expires before the proposed date; leave out credential documents, personal contact details and the reason someone is absent. The first conversation needs the rule and its consequence. It does not need the underlying staff file. If the example involves substitute coverage, describe a building requirement and an adult candidate pool, with no class list or details about children.

Agree what would count as a useful result

A small evaluation should answer three questions. Can the shift be described clearly enough for another manager to read it? Can the team explain why a candidate is eligible or excluded? Can everyone distinguish a proposed replacement from confirmed coverage? Agree those checks before discussing more sites. Otherwise a polished board can look successful while the same unresolved decision still travels through email and phone calls behind it.

Include an intentionally difficult case. Give one candidate the wrong window and another a credential record that does not cover the date, then discuss the uncovered outcome. An evaluation in which every candidate qualifies never shows whether the refusal is understandable. This is a proposed walkthrough to arrange with us, not a test running in this marketing page. The shift-roster board remains early access, and a conversation does not create an account or promise access on a particular date.

Leave with a bounded next step

Before any pilot, ask which screen can actually be shown, which records an operator would supply, who can approve an assignment and how a failed attempt will be reviewed. Put the answers beside your example. If the necessary surface is still being built, the next step may be a follow-up when that surface can be demonstrated. A requirement can be a good fit for the direction of the product without being ready for a rollout this month.

Keep the current coverage procedure available during an evaluation. Do not replace an operational contact list because a marketing conversation went well. Widen only after the people responsible for the first shift can explain both the accepted result and the unresolved cases. Planned pricing on the home page is context for that discussion, not an invoice. Contacting us, reviewing a scenario or reserving early access does not authorize a charge, sign a contract or provision a live roster.

Name the constraint that could stop a pilot

If you cannot evaluate a tool without a particular deployment arrangement, calendar connection or operator permission, put that in the first message. We should discuss the blocking requirement before asking you to review an easy matching example. Likewise, if a legal, procurement or data-handling review comes first, name the review and the documents you need. This public page does not establish a negotiated retention term, support response time or service commitment.

For an existing discussion, include the page path and a plain description of the question you were trying to answer. Redact staff details from any illustration. Do not send passwords, session links, credential documents or records about children. If the conversation eventually requires operational material, agree the appropriate handling route first. The privacy page separates an adult scheduling example from the larger personnel file it does not need to contain.

An email starts a conversation, not a rollout

The most useful outcome is a shared description of the requirement, an honest statement of what can currently be shown and a bounded next step. That may be a walkthrough, a question for the person who owns your roster process or a decision to wait for an early-access surface. No button on this page grants access or changes a staff assignment. There is no live purchase flow, and published pricing remains a plan for discussion.

If your need is outside scheduled coverage, say so. A person looking for a personal appointment link should not be led through a substitute-roster conversation. A team looking for records of work actually performed has a different job to solve. The about page explains the boundary, and the surface guide helps identify the action you need before you spend time describing the wrong workflow.