Hotel hiring is not finished when the offer is signed.

An accepted offer is a commercial milestone. It is not an operational finish line.

Hotels often measure recruitment as if the difficult part ends when the candidate accepts.

A vacancy was approved. The job was advertised. Candidates were screened. Interviews happened. An offer was sent. The candidate said yes.

The recruitment dashboard improves.

Operations can still be weeks away from having a person who can actually work.

Between offer acceptance and first shift, hospitality creates a second workflow that is usually less visible and more fragmented than recruitment itself.

Documents have to be correct. Work authorisation may need action. Travel may need coordination. Accommodation may need a bed. Transport may need a route. Uniform and equipment may need to exist. System access may need to be provisioned. Training may need to be completed. A department head needs to know when the person is actually coming.

If those tasks live across spreadsheets, email, WhatsApp and memory, the hotel can be “fully recruited” on paper and still not be ready to operate.

Recruitment owns a candidate. Operations needs a productive employee.

That gap is the category problem.

Most people systems are good at one or more parts of the lifecycle.

An ATS manages applicants and hiring stages. A core HR system maintains employee records. A payroll system handles salary and statutory processing. A learning system manages courses. A document tool issues letters.

Those are useful systems.

The hotel-specific problem appears between them.

Who is accountable for the whole journey from approved headcount to a person who can begin the job, get what they need after joining and continue developing without every request becoming an HR chase?

If the answer is “HR,” that is not yet a system design.

It is a department name.

The hotel people lifecycle begins before the job advertisement.

The first control is approved headcount.

Before a vacancy becomes a hiring task, the hotel should know:

• whether the position is approved
• whether it is replacement or growth
• what budget sits behind it
• what entity and property employ the role
• what department and cost centre own it
• what work-authorisation or localisation conditions apply
• when the role is actually required operationally

This sounds administrative until the hotel is in pre-opening.

Then the consequence becomes obvious.

A recruitment team can fill vacancies quickly and still fill the wrong shape of organisation if approved headcount, budget, role requirements and opening dates are not connected.

The manpower plan is not a spreadsheet beside recruitment.

It is the first state in the same operating journey.

Careers is part of the operating system too.

Hotels often treat the careers page as an employer-branding asset maintained by marketing or corporate HR.

It is also a distribution surface for labour demand.

A strong owned careers layer should help the hotel answer practical questions:

• Which property is hiring?
• Which department owns the role?
• Is the job still genuinely open?
• What source produced the application?
• Can the candidate apply properly on a phone?
• Can the group publish the same vacancy across its own brands without creating duplicate records?
• Can approved external hiring channels receive the job without becoming the only place the hotel owns candidate demand?

This is the people equivalent of a hotel direct-booking problem.

If the hotel creates the demand but the entire relationship lives inside somebody else's platform, it gives up control too early.

That does not mean job boards are bad.

It means the hotel should still understand its own candidate journey and source quality.

Offer acceptance should trigger a mobilisation plan, not a celebration email and a spreadsheet row.

Once the candidate accepts, the workflow changes.

The question is no longer:

Should we hire this person?

It becomes:

What has to be true before this person can start safely and productively?

Those requirements are role-specific and location-specific.

For one person they may include:

• passport and identity evidence
• work-authorisation steps
• medical or certification requirements where lawful and necessary
• travel details
• arrival coordination
• employee accommodation
• transport eligibility
• uniform sizing
• equipment
• property access
• PMS, POS, email or other system access
• department induction
• mandatory training
• probation objectives

The exact list varies.

The design principle does not.

Each requirement should have a state, an owner, a deadline and evidence where evidence is actually required.

“HR is following up” is not a readiness status.

Readiness is one view inside a much larger people product.

This is why Hotel Workforce Readiness was the wrong public name for the broader Katalyst people platform.

Readiness matters enormously, especially for pre-openings and international mobilisation.

But it describes one chapter.

After the person starts, they still need a usable relationship with the organisation.

They may need to:

• request annual leave
• obtain a salary certificate
• update approved personal details
• receive a policy or official document
• complete mandatory learning
• see required certifications
• understand probation objectives
• request support
• move between properties or roles later

If every one of those requests falls back to email, WhatsApp or “ask HR,” the organisation has digitised the employee record but not the employee experience.

Employee self-service should remove chasing, not create another portal people avoid.

A weak self-service platform is easy to recognise.

Employees use it because HR told them to.

They still message HR afterwards to ask whether the request worked.

A useful employee service should make four things clear:

1. What can I request?
2. What information is required?
3. Who owns the approval now?
4. What happens next?

Take a salary certificate.

From the employee's perspective, the job is simple:

I need an official salary certificate for a specific purpose, language and recipient.

Behind that request, the hotel may need policy rules, approval, a controlled template, salary-field permissions, official rendering and an auditable issuance record.

The employee should not need to understand that machinery.

They should know the request is valid, where it is and when it is complete.

That is a product problem, not only an HR process problem.

Leave is another good test of whether workflow and hotel operations are connected.

A leave request is not just a date range.

The hotel may need to understand:

• employee entitlement
• manager approval
• delegation
• department coverage
• blackout or operational constraints where lawful and policy-approved
• payroll or HR consequences
• return date

A generic form can collect the dates.

A useful workflow makes the ownership and consequence clear without turning every manager into an HR administrator.

Training becomes more useful when it is attached to the role and operation.

Hotels already train people.

The problem is rarely the existence of course content.

The harder questions are:

• Which training is mandatory for this role?
• What must be complete before first shift?
• What certification is expiring?
• Which objective belongs to probation rather than onboarding?
• What development becomes relevant after the employee is productive?
• What changes if the employee transfers to another property or brand?

A learning system can remain the delivery tool.

The hotel people platform should still understand why the learning exists and what operational state depends on it.

That is the difference between course completion and workforce capability.

Pre-opening exposes every disconnected people process at once.

A hotel opening compresses the lifecycle.

Hundreds of positions can move through approval, recruitment, offer, mobilisation, accommodation, access, training and joining at the same time.

A problem hidden in steady-state operations becomes visible very quickly.

The GM wants to know:

• how many approved positions are still unfilled
• who has accepted but is not cleared to join
• what documents are blocking arrival
• which departments are exposed
• whether accommodation or transport is becoming a constraint
• what mandatory training is incomplete
• who can actually start on the required date

This is not a normal ATS question.

It is not a payroll question either.

It is hotel people operations.

The platform should not automate the employment decision away from accountable people.

People software needs a stricter boundary than many commercial systems.

A system can help with:

• workflow routing
• document completeness
• approved screening questions
• interview structure
• duplicate detection
• scheduling
• reminders
• evidence collection
• required training
• policy-controlled approvals

It should not quietly turn a model score into an employment decision.

It should not infer protected characteristics.

It should not invent personality or suitability from weak signals because a hiring manager is busy.

And sensitive information such as salary, identity, medical or grievance data should not inherit the same access rules as an ordinary operational note.

Convenience is not a sufficient reason to weaken governance.

The useful product category is broader than HRMS and narrower than “everything people.”

Katalyst People is the HR and workforce platform for the people behind the welcome.

The intended lifecycle is:

Attract → Hire → Prepare → Start → Serve → Learn → Request → Grow

That position leaves room for specialist systems where they already make sense.

Payroll does not need to be rebuilt simply to make the platform feel complete. External hiring channels can remain useful. Learning content can come from specialist providers.

The value sits in the hotel-native operating layer connecting the journey and making ownership visible.

Explore the people journey in a private demonstration. Current capabilities, launch requirements and data preparation are agreed before implementation. The Katalyst People page explains the product and how to get started.

A useful test for your current people stack

Pick one recent employee who joined the hotel.

Then reconstruct the journey from approved vacancy to today.

Count how many times the process left the system of record and became:

• a spreadsheet row
• an email thread
• a WhatsApp message
• a personal reminder
• a document saved locally
• a verbal follow-up

Then ask the same employee how they request leave, obtain an official letter and find required training now.

If the answer relies on the same informal channels after joining, the problem is larger than onboarding.

The hotel has several people systems.

It does not yet have one people operating journey.