You've finished the rota.
After a few hours of moving shifts around, checking everyone's hours, fixing the close-open you accidentally gave your supervisor, adjusting Saturday for the football and finally getting the wage percentage somewhere respectable, the week is ready.
Excellent.
Now open the payroll system and type the whole thing in again.
Sarah, Monday, 17:00 to 01:00, thirty-minute break. Then Tuesday. Then the next employee, and the next one, until the rota you have already built, checked and approved exists for a second time in another piece of software.
We've seen versions of this process across plenty of hospitality businesses. Sometimes the rota starts in Excel because the payroll platform is painful to schedule in. Sometimes managers prefer another workforce tool but still need the final version entered elsewhere. Some businesses use exports and imports, although those can quickly become their own little administrative adventure.
Different systems, same basic problem.
The manager ends up carrying the information from one place to another by hand.
Nobody planned it that way. It just became part of the job.
Why do hospitality managers end up entering the same rota twice?
Most hospitality technology stacks grew gradually rather than arriving as one neat masterplan.
A business chose an HR or payroll platform years ago. Employee records live there, payroll runs through it, finance knows it, and hundreds or thousands of people depend on it working every month. Replacing that system just because managers dislike writing rotas inside it would be an enormous decision.
Then another product comes along that does scheduling better.
Bookings live somewhere else. EPOS has its own reporting. Training has another login. Stock, maintenance, guest feedback and events may each have their own systems too.
Individually, each tool can be perfectly useful. The admin appears in the gaps between them.
Someone downloads a file from one system and uploads it into another. A spreadsheet gets cleaned. Names are matched. Hours are copied across. The final rota gets checked against whatever payroll expects before someone can finally close the laptop.
Nobody announces that the General Manager is now responsible for moving data between the company's software.
They simply discover that Tuesday afternoon has disappeared.
We keep saying managers should spend more time on the floor
This is one of my favourite contradictions in hospitality.
Ask almost any Ops Director what they want from their GMs and you'll hear some version of the same answer: spend more time with the team, drive standards, coach managers, understand the guest journey, build sales and lead the business.
All sensible.
Then look at the administration we give them.
Enter these start times.
Copy those breaks.
Update this spreadsheet.
Check the spreadsheet against that screen.
Re-enter the shifts somewhere else.
There are plenty of administrative jobs that genuinely deserve a manager's attention. Reviewing payroll does. Investigating unusual wage movements does. Looking at whether the rota is commercially sensible absolutely does.
Typing 17:00 into a second box after you've already decided somebody starts at 17:00 does not require much leadership.
And yet managers routinely spend meaningful chunks of their week doing exactly this while the same business tells them to get out of the office.
How much time does double entry actually waste?
Take a reasonably large venue with 50 employees and around 150 shifts in a week.
For each shift, imagine you need to enter or confirm just four pieces of information in the final system: start time, finish time, break and department.
That's 600 individual pieces of information.
Even if each one takes only five seconds to find, enter, check and move on, you're at around fifty minutes. At ten seconds per item, which starts feeling more realistic once pages load slowly, departments need expanding, people interrupt you and the odd shift refuses to behave, you're closer to 100 minutes.
Across a year, that can easily become more than eighty hours of management time.
Two working weeks.
And that example is fairly conservative. Larger venues may have more shifts, more departments, more breaks, overnight finishes and far more opportunities for the process to slow down.
The strange part is that hospitality businesses will debate five unnecessary floor hours with forensic intensity while quietly accepting days of management time disappearing into repetitive data entry.
Double entry creates two chances to get the same decision wrong
The wasted time would be irritating enough on its own, but every manual handoff also creates another opportunity for the two systems to disagree.
Imagine you've finished the rota and started entering it into payroll. Halfway through, someone messages to say they can no longer work Thursday. You update the rota, move the shift to somebody else and continue with your day.
Did you remember that you had already entered the original Thursday shift in the other system?
Hopefully.
Maybe Sarah now appears as working 17:00 in one place and 19:00 somewhere else. Perhaps an overnight finish gets typed incorrectly, a break is missed or the wrong James gets selected from a list containing three Jameses because apparently every hospitality team must have at least that many.
None of these mistakes are particularly dramatic. Most get fixed.
They still need to be found first.
Once multiple systems contain slightly different versions of the week, somebody has to decide which one reflects what was actually intended.
That problem gets more interesting across a group, where dozens of managers are carrying out the same process with different habits, different levels of experience and wildly different amounts of patience.
“Just export it” helps, until it doesn't
The obvious solution is to export the rota.
Download a spreadsheet or CSV, upload it into the payroll platform, and you're done.
When that works cleanly, it's brilliant.
Anyone who has spent enough time around hospitality spreadsheets will know that the phrase “just upload the CSV” is often doing a heroic amount of work.
Column names need changing. Employee names don't quite match. One system calls a department “Restaurant” and the other calls it “Floor”. Dates have somehow become American. Blank rows cause mysterious errors. Excel decides that something which clearly isn't a date would look much nicer as one.
Soon the 'automated' process has a six-page instruction guide and a precarious set of formulas that break everything if you paste over the wrong bit.
Exports are still enormously useful, and in many businesses they remove a huge amount of manual work. The point is simply that moving the typing into a spreadsheet hasn't always removed the admin; sometimes it just gives the admin a nice hat to wear.
The manager should ideally be checking the unusual bits rather than manually shepherding every ordinary shift from one place to another.
Why don't the systems simply talk to each other?
Sometimes they do, and when a proper connection between platforms works well, that is usually the cleanest answer.
Hospitality rarely gives you a perfectly connected set of systems, though.
Groups use different software, different versions of the same software and systems that may have been chosen long before the current operations team arrived. Some are deeply embedded across payroll, HR and finance, making replacement far more disruptive than the scheduling problem itself.
That creates an awkward middle ground.
You've found a better way to build the rota, but you don't want to replace the payroll platform.
The old answer is usually to keep building the rota in whichever system works best, then manually transfer the finished version into the place where payroll needs it.
We thought there had to be a better option.
This is one of the reasons we built GlassRota
I've never seen the point in pretending a problem exists so we can secretly sell software.
The problem described above is one we've experienced firsthand, endured for years, and chose to build directly around.
I have often argued that a rota deserves more scrutiny than a grid of names and times. A legal rota can still be operationally poor. Cutting labour can damage the sales you're trying to protect. Even a carefully forecast rota needs enough flexibility to survive the week behaving differently from the spreadsheet, as we explored in Your Best Rota Should Be Slightly Wrong.
That thinking eventually led us towards a simple workflow:
Draft. Diagnose. Publish.
Build the week in GlassRota, check it properly, make the adjustments you need, then send the approved schedule onwards to the system your business already uses.
The plan sounded simple, and our validation engine worked exactly as we hoped, producing people-focused and business-focused checks while the rota was being built. Then the obvious problem appeared almost immediately.
If GlassRota saves a manager an hour while they build and check the rota, then forces them to spend another hour retyping everything afterwards, we've simply moved the frustration further down the process.
So we built the Publish Assistant.
What does the Publish Assistant actually do?
In plain English, it helps take the rota you've already finished and move those shifts into the existing payroll or workforce system without asking you to type every start time, finish time and break again.
You keep the system your business already relies on.
You still review what's happening.
If something doesn't transfer properly, the manager deals with that specific exception rather than recreating the entire week manually.
For supported systems, the aim is very simple: make the decision once.
If Sarah is working 17:00 until 01:00, the manager should spend their time deciding whether that is the right shift, not proving they can type 17:00 and 01:00 accurately in two different places.
We've started referring to the principle internally as:
Think once. Type once.
That probably sums it up better than anything more technical ever could.
Automation should remove repetition, not judgement
There is an important distinction here.
I would be uncomfortable with a system that took hundreds of rota entries, silently threw them into payroll and then gave the manager a cheerful green tick without showing what had happened.
People get paid from this information. Quietly assuming everything worked isn't good enough.
A better process handles the predictable work while keeping human attention on the exceptions.
If 148 out of 150 shifts transfer successfully, the useful message is not “Success!”
The useful message is:
148 shifts are done. These two need you.
Now the manager can spend five minutes solving something unusual rather than ninety minutes entering everything, including the 148 completely normal shifts.
That is where automation genuinely helps hospitality.
Managers don't need software to remove every decision from their job. They need fewer repetitive tasks competing for the attention required to make the important decisions well.
Do you need to replace payroll to improve how you build rotas?
For plenty of businesses, no.
Your existing HR or payroll platform might be completely fine at the jobs you originally bought it to do. Employee records live there, finance understands it, payroll works and nobody in head office has any desire to start a twelve-month software migration because the scheduling screen annoys the GMs.
Fair enough.
There is a much smaller question to answer first:
Can the rota itself be built and checked better without disrupting everything underneath it?
That's the position GlassRota was designed around.
Keep your existing setup where it works. Improve the part that doesn't. Make the journey between the two as painless as possible.
Hospitality technology projects have a habit of becoming enormous very quickly. Sometimes the useful answer is considerably less dramatic.
Want to try the workflow on a real rota?
I'd genuinely recommend skipping the fluff and simply trying GlassRota yourself.
Start a free 14-day GlassRota trial →
Build an actual week, use the diagnostic tools to check it, and see how the process compares with whatever you're doing today.
You'll learn far more from one real rota than from a polished software demo full of beautifully behaved fictional employees.
The expensive bit is the manager's attention
Most of these administrative tasks look harmless individually.
Download this file, copy those hours, check that number, enter these shifts.
Five minutes here. Ten minutes there.
Across every week, every venue and every manager in a group, however, the numbers become harder to ignore.
There will always be administration in hospitality. Payroll should be checked carefully, rotas should be reviewed properly and managers should absolutely remain accountable for the decisions they make.
Repetitive typing deserves far less protection.
The point of good hospitality technology should be to give people more time for the work that actually benefits from having a human being involved: judgement, coaching, commercial thinking, problem solving and looking after the team and guests in front of them.
If a manager has already decided Sarah works 17:00 until 01:00 on Saturday, reviewed the shift and approved the week, asking them to communicate the exact same decision to another screen doesn't improve the rota.
It simply asks them to be accurate twice.
Surely we've got better things for them to do.
