Getting casuals off the group chat: the first-fortnight rollout plan for a rostering app
Casuals take to a rostering app when it gets them shifts in the first week, and drop it while the group chat still works. Here is the fortnight that moves a 22-staff pub, day by day: one announced date, the first roster in both places, the second in the app only, and the three numbers that tell you it stuck.
Casuals take to a rostering app when it gets them something in the first week, and the something is nearly always shifts: a Saturday they would not have heard about, a swap sorted without ringing the manager, their hours in front of them before payday. They drop it when the group chat still works. If a screenshot in the chat is still the fastest way to find out whether you are on tonight, the app is a second place to look, and nobody checks two places for long.
You know the week this piece is about. The roster is in the app, and has been for three days. On Thursday night someone posts a screenshot of it in the chat anyway, out of habit, and three people reply to the screenshot. One casual says her phone is full and she will download the app later. And the head chef, who has had it since Monday, is still texting his section their shifts, one message each, the way he has for four years. The roster is in the app. The app is not yet the roster.
The short version: a rostering app sticks with casuals when it is the only place shifts appear, and it gets there inside a fortnight when the rollout is run that way on purpose. Announce the date the chat stops carrying shifts. Put the app at step two of the paperwork. Publish the first roster in the app and the chat, the second in the app only, and move the managers before the staff, because a kitchen whose head chef still texts never moves. By the end of week two you should be able to say how many staff have set availability, how many "am I working tonight?" messages you got, and how long the last sick call took to fill. This is general information, not legal advice: the Fair Work Ombudsman is the source of truth for the Hospitality Award (MA000009).
Why casuals adopt faster than owners expect
Owners expect resistance because they are picturing the admin side: another login, another thing staff have to be told to do. Casuals see it from the other end. For someone on 15 hours a week, a shift is money, and the person who sees the shift first is the person who gets it.
In the chat, a Saturday that opens up at 3pm goes to whoever the manager thinks of first, or whoever happens to be looking at their phone. In the app, it goes to everyone who can take it, at the same time, and the first hand up is in front of the manager rather than buried in a text thread. A casual works that out on the first open shift they miss, and from then on they look at the app.
Availability is the other thing that pays them. Entered once, for each day of the week, it means the uni student is not rostered on her Tuesday lecture for the fourth week running and then made to find her own cover for it. That is a shift she does not have to give back, and a conversation she does not have to have.
Casuals rarely quit out loud. They take one shift instead of three, then stop answering the roster message, and we have costed what that quiet exit does to a venue. An app that shows them more shifts and rosters them on days they can actually do is working against that drift from the first week. So the adoption problem is usually smaller than owners fear. The problem that remains is the chat, and the chat is yours to close.
The first fortnight, day by day
This assumes the setup is done: team imported, departments and positions built, award levels assigned, manager permissions set. That is the fortnight migration plan in our Excel guide, and it comes before this one. This fortnight is about people, not configuration. The pub is the same one as that guide: 22 staff, 6 permanents and 16 casuals across bar, kitchen and floor, the venue manager and the head chef both editing the roster, and a week's roster published on Thursday night.
| Day | What happens | Where the roster lives |
|---|---|---|
| Day 1, Monday | Announce with a date. One pinned message in the chat: from Thursday week, shifts are in the app and nowhere else. Name the day. Managers install the app today and publish nothing from anywhere else from this point on. | The chat, for the last time |
| Days 2 to 3 | Onboard. The app invite goes out with the paperwork, so a new starter installs it at step two, before the bank details. Existing staff install it at the start of their next shift, two minutes at the pass with a manager watching, and set their availability before they leave. | The chat |
| Day 4, Thursday | First roster published in the app and in the chat. Same roster, same night, on purpose. The notification lands on every phone with the app; the screenshot goes up for everyone without it. | Both |
| Days 5 to 7, the weekend | Every change goes into the app only. Someone swaps Saturday, it is offered and approved in the app. "Am I working tonight?" gets one reply: it is in the app. Count those messages. | Both, changes in the app only |
| Day 8, Monday | Managers first. The head chef edits the kitchen in the app and texts nobody. One publish path, one approval path. Walk the floor with the list of who has not installed it and do it with them. | The app, with the chat lagging |
| Days 9 to 10 | Build the second roster with the availability view on. Chase the names with no availability set, in person, not in the chat. | The app |
| Day 11, Thursday | Second roster published in the app only. Nothing goes in the chat. A printed copy goes by the till for anyone who needs it. | The app, printed copy at the till |
| Days 12 to 14, the weekend | The first sick call of the new system. The shift is offered out from the app, picked up and approved there. Note the time from the call to the filled shift. | The app |
| End of day 14 | Take the three measures below. The chat is for banter from here. | The app |
Two sources of truth for one roster cycle is a handover. For two cycles it is a habit, and the habit that wins is the one with four years behind it. The first roster goes in both places so nobody misses a shift in week one. The second goes in the app only so nobody can keep treating the chat as current. That overlap is deliberate and it is short. Stretch it to a third roster and the chat wins, because the chat is the thing your staff have had since they started and the app is the thing they have had for ten days.
If you publish a fortnight at a time, read each week above as a roster cycle: first cycle in both, second cycle in the app only. The plan takes a month instead of a fortnight, and the rule about the overlap does not change.
Do not phase it in by department. It looks careful, and at a 22-staff pub it is the opposite, because people cross departments. The casual who works the bar on Friday and the floor on Saturday ends up with two rosters, two places to look, and nobody checking that the two shifts fit together. If staff work across departments, everyone moves on the same Thursday. The only staging that works is by roster cycle, not by room.
Lead with the two features that pay them
The first week of an app is a pitch to your own staff, and the pitch is money in their pocket, not admin out of yours. Two features do that, and they are the two to set up and talk about before anything else.
Availability. In Shiftly Me a casual marks each day of the week as available, unavailable or a time window, once, and changes it when their timetable does. It shows on the roster grid while you build, and a shift dragged onto a day someone cannot do gets a warning before you publish. For the casual it means one fewer shift to give back. For you it is the end of decoding the chat for who can do Tuesday.
Open shifts and swap requests. When someone cannot make a shift, they offer it out in the app, and the manager approves the swap from their phone. When a shift opens up at your end, you offer it to available staff from the app instead of texting three people. We have costed what the self-service version saves a manager. For the casual the point is simpler: the extra shift is visible to them, in the app, before it goes to whoever the manager thought of first.
Clock-in, breaks and timesheets come once the roster is the roster. They pay you first, and you want the first week to pay them.
Managers first
If the head chef still texts the kitchen, the kitchen never moves. Not because the cooks are stubborn, but because the thing they need arrives by text, and a text from the chef is the roster as far as the kitchen is concerned. You can get every casual on the bar into the app and the kitchen will still be run from a phone in the chef's apron.
So the managers move on day one, not day eight, and they move on two rules. One publish path: a shift exists when it is published in the app, and a shift that was texted was not rostered. One approval path: swaps, open shifts and leave are approved in the app by the person with permission for that department, and "yeah that's fine" in a text is not an approval. The head chef edits kitchen and functions, the bar manager edits bar and floor, the venue manager publishes. Shiftly Go puts those approvals on the managers' phones with a push notification, so the argument that texting is quicker does not survive the first week.
The honest part: the head chef is the hardest person to move, not the holdout casual. He has a system that works for him and a section that answers him, and the fortnight asks him to give up the thing that makes him fast. Sit with him on day one, build the week's kitchen roster together in the app, and do not let him send the texts for the first roster. If he sends them, he has published a second roster, and you are back to two sources of truth with the chef's name on one of them.
Casuals do not resist the app. They resist the second place they have to look.
The holdouts
Josh is a Level 2 on the bar, three or four shifts a week, two years at the pub, and he has had the app on his phone since day two, unopened. On day eight at the pass he says what every venue hears from someone: "I'll just check the chat." He is not being difficult. The chat has told him his shifts for two years and it told him last Thursday, so from where he stands the app has not yet done anything the chat does not.
The honest answer is the only one that works, and it is two sentences. The roster is where the roster is, and from Thursday it is in the app. And the app is where the extra shifts appear, so when Saturday opens up at 3pm it goes to the people looking at it. That is the whole pitch. Not a talk about the future of the business; one place to look, and more shifts for the people who look there.
Then stop arguing and let the second roster do the work. On day 11 the roster lands in the app and not the chat, and Josh finds out his Friday from a notification or from the printed copy by the till. A week of that and the chat becomes what it was always going to be: photos from the staff party and someone selling a bike.
Her phone is full. That one is real, and the answer is two minutes at the till deleting something, not a conversation about commitment. The app is free, so the cost is storage, and storage is a solved problem on a Tuesday afternoon. If she still will not, she reads the printed copy and gets the chat's old deal: her shifts, and nothing extra. Her availability goes in anyway, because a manager can enter it from her profile, so she is rostered on days she can do like everyone else. What you do not do is build a text channel for one person. That is the second source of truth coming back with a name on it.
How you know it has stuck
Three measures at the end of week two. Write the week-one numbers down on day seven so you have something to compare against.
- Share of staff who have set availability. Count heads, not percentages. At the 22-staff pub that is 16 casuals, so you want 16, and you want the names of any you do not have. A casual with no availability in the app is still being rostered from memory, which is the chat by another route.
- "Am I working tonight?" messages per week. Count them in week one; you will have a number by Sunday. By the end of week two it should be close to none, and every one left is a name to walk over to rather than a reply to send.
- Time from a sick call to a filled shift. The old version was forty minutes of messages and a favour owed. Time the first sick call of week two, from the phone ringing to the shift showing as covered in the app. The number is yours. What matters is that the manager did not text three people to get it.
Three out of three and the plan worked. Two and it is close, and the missing one tells you where to look. One, and the chat is still carrying shifts somewhere, usually in a department whose manager is still texting. Go and find the phone.
Where Shiftly fits
We built the two halves of this fortnight as two free apps. Shiftly Me is the staff app, on iOS and Android: a casual sees their upcoming shifts and who they are on with, sets availability for each day of the week, offers a shift out when they cannot make it, clocks in and out from their phone within the venue's geofence, and can look back at past shifts, hours and wages. Shiftly Go is the managers' app: build and publish the roster from a phone, approve swaps, timesheets and leave as the push notification arrives, offer an open shift to available staff, see who is clocked in live, and message the team in group chats inside the app, without anyone's personal number. When you publish, staff are notified in Shiftly Me with their shift details, and a change pushes through to the people it touches. Availability sits on the grid as you build, with a warning when a shift lands on someone who is unavailable and a block on double-bookings.
Shiftly is a calculation tool and a staffing network, not a payroll provider. The award interpretation helps estimate what a shift costs at each person's level; the business stays responsible for verifying it, and the Fair Work Ombudsman is the source of truth. The core platform is free at every headcount, with no per-employee fees, so the 22-staff pub pays what a 12-staff cafe pays. The half of the job no group chat ever did is the shift nobody on staff can take: from inside the roster, that open shift can go out to a network of local hospitality workers. That network is coming soon, starting in Sydney, and the waitlist is open.
Frequently asked questions
Can I require staff to use a rostering app?
Be careful here, because the award does not say what you might want it to. Clause 15.5 of the Hospitality Award, headed Rosters (Full-time and part-time employees), says at 15.5(c) that "the employer must post the roster in a conspicuous place that is easily accessible by the employees". It does not mention apps, and nothing in it gives you a right to require a personal phone to carry one. So do two things. Make the app the place the roster is published and the place open shifts appear, which is what moves people. And keep a printed copy by the till through the changeover and after it, so the posted roster is there for anyone without the app. The award also now carries a right to disconnect at clause 15A, under which an employee may, unless it is unreasonable, refuse to monitor or respond to contact from the employer outside their working hours. A roster notification is something staff read when they next look, not something they owe you at 11pm. This is general information, not legal advice.
What happens to the group chat after the changeover?
Keep it, and keep shifts out of it. Banter, photos, who is bringing what to the staff party. The day a shift is posted in it again, do not repost or correct it there; reply that it is in the app, and put it in the app. Managers do not answer roster questions in the chat either, because every answer there is a reason to keep asking there. If you would rather have work talk off personal numbers altogether, Shiftly Go has group chats inside the app, and a manager can drop shift details straight into the conversation, which is the one kind of message a roster chat was ever good for.
Should I roll the app out one department at a time?
Not if staff work across departments, and at a 20-plus staff pub they usually do. Phasing by room gives the casual who works the bar on Friday and the floor on Saturday two rosters in two places, and it gives the department still on the chat a reason to stay there. Stage by roster cycle instead: first roster in both places, second roster in the app only, everyone on the same Thursday. The one exception is a department with its own staff who never cross over, and even then set its date before you start.
How long should the roster be in both the app and the group chat?
One roster cycle. For a venue publishing weekly that is one week; for a venue publishing fortnightly it is one fortnight. The first roster goes in both so nobody misses a shift while the app is new. The second goes in the app only, with a printed copy by the till. If the roster is still in the chat for a third cycle, the chat is the roster again, and you will do the whole fortnight a second time.
The bottom line
Casuals move to the app in the week it gets them a shift, and they stay when it is the only place shifts appear. At the end of week two you want three numbers: how many of your staff have set availability, how many "am I working tonight?" messages you got, and how long the last sick call took to fill. Run the fortnight migration plan first so the setup is done, put Shiftly Me on the staff phones at step two of the paperwork, and then do the one thing this plan turns on. Pick the date the chat stops carrying shifts, and tell them the date.
Co-founder of Shiftly. Milan works with hospitality businesses across Australia to make rostering, timesheets and award-based pay radically simpler.
