Hospitality Staff Services is a production workforce management system designed by Softech for a staffing agency serving hospitality operations in London and Dubai. The solution connects an operations web panel and worker mobile application into one process covering client demand, workforce availability, shift planning and assignment, check-in/out, timesheets, documents, time approval and settlement preparation across different cycles. A shared data model tracks the transition from a planned shift to approved working time and settlement-ready records. The system was also extended to event and crew staffing. This public description presents supported product and process scope; previous percentage-based KPIs and the client quotation are not published without an approved source.
Business context and the situation before implementation
A staffing agency serving hotels, restaurants and hospitality operations must align client requirements, worker roles, availability, location, rates, documents and settlement timing. Each shift is a small operational transaction, but across multiple locations and payout cycles the number of dependencies grows quickly.
- Client demand defines location, role, date, headcount and settlement rules.
- Worker availability must be evaluated together with skills, documents and existing assignments.
- Time records affect worker settlement, client reporting and accounting data at the same time.
- Different settlement cycles require the work event to be separated from the moment a payout is prepared.
- Operations in London and Dubai require multi-location, time-zone and business-configuration support.
Before state
Before the workflow was unified, rosters, availability, attendance confirmation, timesheets and settlements required information to be reconciled across several sources. Each shift correction could affect the client, worker and settlement, so the operations team needed a system with clear states and preserved history.
- Rosters and availability were difficult to reconcile in one operational view.
- Shift changes, replacements and time corrections increased the number of manual reconciliations.
- A timesheet required review before it could become settlement input.
- Different rates and allowances created multiple settlement variants.
- Worker documents and client requirements had to be checked before assignment.
- Reporting and accounting exports required operational data to be prepared first.
Goals, success criteria and constraints
The work started by mapping staffing as a set of states and decisions rather than a list of screens. The team mapped client demand, worker availability, shift, assignment, attendance confirmation, timesheet, rate rules and settlement, then identified the points that require an operator decision.
Product goals
- Create one workflow from client staffing demand to approved working time.
- Connect shift planning with worker availability and mobile assignment handling.
- Capture check-in/out and timesheets in a form that can be validated and corrected.
- Move settlement rules away from manual spreadsheets and repeated calculations.
- Connect worker profiles, documents and checklists with assignment eligibility.
- Prepare reporting and export data without copying records between tools.
- Allow the same model to extend to new assignment types, events and crews.
Success criteria
- An operator can see demand, staffing and each shift state in one system.
- A worker can declare availability and manage an assigned shift from the mobile application.
- Recorded time can be traced from check-in/out to an approved timesheet.
- Settlement preparation uses approved operational data and assigned rate rules.
- Documents and checklists are available before an assignment decision is made.
- The system separates different settlement cycles without duplicating work records.
- A new assignment type can reuse the shared worker, shift and settlement model.
Multiple roles and locations
Shifts differ by role, location, hours, client and requirements, so planning cannot rely on a calendar alone.
Changing availability
Worker availability and replacements change close to delivery time, so the system must support corrections without losing history.
Time-dependent settlement
Hours, nights, weekends, allowances and other components must be calculated from approved time rather than the roster alone.
Different payout cycles
Work performed in the same period may enter different settlement cycles, so the work event and payout must remain separate stages.
Documents and requirements
Worker assignment should account for profile completeness, documents and checklists required for a given work type.
Multi-market operations
London and Dubai require location, time-zone, currency and business-rule configuration without creating two separate products.
Analysis and product decisions
- A planned shift was separated from the assignment of a specific worker.
- Availability was treated as planning input rather than a static profile attribute.
- Check-in/out and timesheet approval were defined as connected but separate time-control stages.
- Rate and allowance rules were connected with client, role and performed-work context.
- Settlement cycles were separated from the underlying completed-shift record.
- Profiles, documents and checklists were connected with eligibility for a specific assignment.
- Exception states were defined for unfilled demand, reassignment, time correction, missing documents and held settlements.
Solution architecture
The architecture separates the operations channel and worker application from shared workforce-management logic. The web panel and mobile application use an API responsible for clients, locations, workers, availability, shifts, assignments, timesheets, documents and settlements. Data is stored centrally, while payment or payout services, accounting, file storage, location and notifications operate as external dependencies.
- 01Operations channel
Workforce operations panel
Demand, rosters, assignments, availability, time approval, settlements, reporting and exceptions.
Next.jsTypeScriptTailwind - 02Worker channel
Mobile application
Availability, assigned shifts, roster, check-in/out, requests and notifications.
React NativeExpoTypeScript - 03Operational logic
Workforce management API
Rules for clients, shifts, assignments, timesheets, rates, documents and settlement cycles.
NestJSPrisma - 04Data
Shared work and settlement state
Central worker, client, location, shift, time, document and operational-history records.
PostgreSQLRedis - 05Integrations
Settlement, files and location
External services supporting payouts, accounting exports, document storage, geofencing or QR and notifications.
Payment/Payout APIXero/QuickBooksS3Maps/Geofencing - 06Operational control
Validation and exception handling
States, holds and manual decisions protect the workflow from settling unapproved time or incomplete data.
Audit trailRole-based accessMonitoring
Problems, decisions and implemented capabilities
The operator must match client demand with workforce availability.
Separate demand, shift and assignment into distinct objects.
Shift planning with visible availability and staffing state.
The team can see which demand is staffed and which still requires a decision.
A worker needs quick access to shifts without contacting an operator for every action.
Move availability and assignment handling into the mobile application.
Availability declaration, roster, shift handling and notifications.
Worker information and decisions feed directly into the shared workflow.
Scheduled time is not sufficient settlement evidence.
Separate check-in/out from the approved timesheet.
Attendance record, validations, correction and timesheet approval.
Settlement can use approved time rather than the roster alone.
Different rates and allowances cause repeated manual calculations.
Move settlement rules into the data model and backend logic.
Rate matrices, allowances, overtime, nights, weekends, advances and commissions.
The same rules can be applied consistently to approved work records.
Different payout cycles mix work execution with the moment it is settled.
Separate the work record from its settlement cycle.
Monthly, weekly and shorter cycles using the same approved records.
A completed shift does not need to be copied into separate spreadsheets for each cycle.
A missing or expired document may prevent a valid worker assignment.
Connect profiles and documents with the operational workflow.
Profiles, documents, checklists and validity controls for worker information.
An operator can check required information before approving an assignment.
Client reporting and accounting require the same data in different formats.
Generate reporting and exports from one operational model.
Client reports, profitability data and accounting-tool exports.
The team reduces manual re-entry before downstream processing.
New assignment types may need different slots, rates and rules without a new system.
Build the workflow on configurable client, location, role and shift models.
Workflow extension to events and crew staffing with their own configurations.
Additional staffing models can reuse the shared operational core.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| Next.js + TypeScript | Operations web panel | The operations interface required component-based architecture, typed data and support for many evolving workflow views. | A rich operations panel requires disciplined data boundaries and client-bundle control. |
| React Native + Expo | Worker mobile application | One application model supports availability, roster, check-in/out and notifications across iOS and Android. | Device- and location-dependent features still require native testing on both platforms. |
| NestJS + Prisma | API and settlement logic | An explicit domain model keeps shift, assignment, timesheet, document and settlement rules outside the user interface. | More domain rules require state-transition testing and careful data migrations when the model changes. |
| PostgreSQL + Redis | Transactional and supporting data | Relationships between client, shift, worker, time and settlement require a consistent transactional model; Redis supports short-lived operational data. | Cache cannot become the source of truth for settlements or approved working time. |
| S3 / object storage | Worker documents and operational files | Files are stored outside the transactional database while the domain record retains access control and profile linkage. | File access must remain separate from merely knowing its location. |
| Maps / geofencing / QR | Attendance control | The project includes mechanisms that connect check-in/out with location or a client confirmation point. | Location or QR supports validation but should not replace the correction and timesheet-approval workflow on its own. |
Integrations and data flows
Accounting — Xero / QuickBooks
System → accountingPass prepared settlement and reporting data into downstream finance workflows.
Exports should use approved records; rejected or incomplete records remain visible for correction.
Payments / payouts
System ↔ financial providerSupport financial stages related to settlements and payouts according to client configuration.
An external-provider status should not be treated as full workflow completion without confirmation in the system.
Document storage
System ↔ storageWorker profiles, documents and operational files remain available in the context of the correct record and permissions.
Access should be authorised, while document removal or expiry must not erase the history of operational decisions.
Notifications and mobile channels
System → worker / operatorAssignment, roster and status changes can be communicated without manual contact in every case.
A message is an information channel; the system state remains the source of truth.
AI, security and reliability
Role-based access
Workers, operators and other operational roles receive access only to data and actions needed for their part of the workflow.
Pre-settlement validation
Timesheets and financial data move through controlled states so unapproved time should not automatically enter settlement.
Change history
Assignment, time and document corrections should leave a trace that explains the basis for an operational decision.
Integration resilience
Exports, notifications and external-provider operations are treated as separate steps that can be retried without duplicating core work records.
Document protection
Worker files require authorised access and linkage with the correct profile and operational context.
Implementation, testing and release
- 101 · Operations analysis
Understand how client demand becomes a shift, assignment, working time and settlement.
- Staffing workflow map
- Role and responsibility model
- Exception and operator-decision list
Result: A shared domain language was established for the web panel, mobile app and backend.
- 202 · Data model and UX
Connect worker, client, location, shift, assignment and timesheet without duplicating information.
- Domain model
- Operations-panel flows
- Worker-app flows
Result: Scheduling and settlements can use the same records instead of separate spreadsheets and copies.
- 303 · Scheduling and mobile app
Launch the daily availability, scheduling, assignment and worker shift workflow.
- Roster and staffing panel
- Worker availability
- Roster, check-in/out and notifications
Result: Operations and mobile channels began using the same shift and assignment state.
- 404 · Timesheets and settlements
Move approved time through rate rules into data ready for reporting or export.
- Timesheet validation and approval
- Rate and allowance rules
- Settlement cycles and exports
Result: Settlement uses a controlled work record and assigned rules instead of manually reconstructing data.
- 505 · Operational extensions
Apply the shared core to additional assignment types without creating a separate system.
- Configurable roles and slots
- Client and location rules
- Event and crew workflows
Result: Additional staffing models can reuse existing worker, shift, time and settlement structures.
State-transition testing
Transitions from demand through assignment, execution, correction, approval and settlement are checked, including invalid shortcuts.
Time and rate rule testing
Scenarios cover different hours, allowances, corrections, cycles and configurations so one rule change does not silently affect unrelated cases.
Mobile application testing
Availability, roster, check-in/out, notifications and device-dependent behaviour are checked on target platforms.
Integration testing
Exports, storage, notifications and financial services are tested for failures, delays and retries as well as successful paths.
Controlled release
Changes to the model and settlement rules require data compatibility and post-release monitoring because they affect operations.
What confirms the project description
The repository contained earlier percentage claims for scheduling time, timesheet errors and automatically filled shifts, but without an approved baseline, comparison period and analytics source. Those figures are therefore not presented as project outcomes in the public version. We confirm only product capabilities supported by the materials and system structure, plus operational information explicitly marked as client-reported.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| The system includes an operations panel for staffing workflows. | Product interface | HS-01 · Existing workforce management dashboard | Confirmed in the product | The screen confirms the operations layer but does not measure time savings or team productivity. |
| The web panel and mobile application use a shared shift, assignment and working-time model. | Solution model | HS-02 · System architecture diagram | Confirmed in the product | The diagram represents logical project layers from provided materials, not confidential production-infrastructure topology. |
| The workflow connects client demand, shift, assignment, work execution, timesheet and settlement. | Process model | HS-03 · Shift and settlement lifecycle | Confirmed in the product | The material confirms workflow structure; it does not measure the duration of each stage. |
| Worker availability and shift staffing are part of a controlled planning workflow. | Operational model | HS-04 · Scheduling, availability and timesheet flow | Confirmed in the product | The diagram does not prove an auto-fill percentage or reduction in manual work. |
| Settlement can use different cycles while retaining one approved work record. | Settlement model | HS-05 · Settlement cycles and payout preparation | Confirmed in the product | The material confirms data-organisation logic; it does not verify payout duration or financial outcomes. |
| The same workflow core was designed for multiple locations and staffing extensions including events and crews. | Project scope | HS-06 · Multi-location model and workflow extensions | Confirmed by the client | Market scope and extensions come from project materials; the publication does not provide independently verified worker or assignment volumes. |
How to read this information
- No approved analytics export is attached for the earlier percentage-based efficiency claims.
- We do not publish the previous sub-24-hour payout claim without source data.
- The previous testimonial remains unpublished until wording and attribution are approved.
- Diagrams represent logical product scope rather than full production-environment topology.
- Client-reported indicates information from project materials rather than an independent Softech measurement.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Workforce planning | Demand, availability and assignments required manual reconciliation. | The system connects demand, shift, availability and assignment in one model. | The operator works from one staffing and exception state. |
| Worker channel | Availability and shift information required multiple operational contacts. | The mobile app handles availability, roster, assignments, check-in/out and notifications. | Worker decisions feed directly into the shared workflow. |
| Time tracking | Rostered and actual working time were difficult to compare and correct. | Check-in/out, validation and approved timesheet create a controlled path. | Settlement input is separated from the shift plan itself. |
| Settlements | Different rates, allowances and cycles required repeated manual calculations. | Settlement rules are connected with approved work records and the selected cycle. | The same work record can feed reporting and downstream finance without creating a separate copy. |
| Documents and eligibility | Document and requirement information was checked outside the main planning workflow. | Profiles, documents and checklists form part of worker and assignment context. | The operator can consider requirements before approving staffing. |
| New staffing models | Each new assignment type risked creating separate rules and tools. | Configurable roles, locations, slots and rates reuse the shared core. | Events and crew staffing can reuse the existing shift, time and settlement model. |
One model for multiple staffing types
- Alternative
- Separate modules for hotels, restaurants, events and crews
- Trade-off
- A shared model requires greater configurability for roles, slots and rates.
- Rationale
- It reduces data duplication and allows new staffing models to evolve without a separate product.
Timesheet as an approval stage
- Alternative
- Automatic settlement from check-in/out alone
- Trade-off
- The workflow includes an additional control step before settlement.
- Rationale
- Correction and approval prevent raw attendance signals from becoming final financial input.
Settlement rules in backend logic
- Alternative
- Calculations in spreadsheets or the operator UI
- Trade-off
- Changing a rule requires controlled release and regression testing.
- Rationale
- Central logic produces consistent results across channels and reduces manual calculation differences.
External integrations as dependencies rather than workflow core
- Alternative
- Tightly coupling the workflow with one payment, accounting or storage provider
- Trade-off
- The integration layer must handle status mapping, failures and retries.
- Rationale
- It keeps the work and settlement model independent from external-provider changes.
Key lessons learned
- In staffing software, the key object is not the calendar but the controlled transition from demand to settlement.
- Worker availability should be treated as operational data connected with a specific period and assignments.
- Check-in/out is an information source, while an approved timesheet should be the input to settlement.
- Different payout cycles are easier to maintain when they do not duplicate the underlying completed-work record.
- Worker documents and requirements are most useful when available at the staffing decision point.
- New staffing models are easier to evolve through configuration of a shared core than through parallel modules.
Which organisations this model is relevant for
Hospitality staffing agencies
Companies combining shift planning, mobile workers, timesheets and different settlement models.
Event and crew staffing operators
Organisations that need to staff temporary slots quickly while retaining consistent time and rate rules.
Temporary staffing companies
Teams that want to connect availability, assignment, documents, time and settlement preparation in one system.
Multi-location organisations
Companies serving multiple locations, time zones or client configurations from one operational platform.
Related expertise and services
Web app development
Operations panels and systems for managing workflows, roles and business data.
Mobile app development
iOS and Android applications for field workers and workflows requiring notifications and device capabilities.
React Native
A shared mobile application layer with access to device capabilities and native integrations.
Next.js
Web layer for advanced operations panels, portals and business applications.
Node.js
Backend and APIs for operational workflows, integrations and domain rules.
Gizo Rental — equipment rental system
A related example of a mobile app and operations panel moving a complex B2B workflow through controlled states.
Foodeli — last-mile logistics
A related example of operations planning, mobile work and field-execution control.
Planning a workforce, scheduling and settlement platform?
We can analyse your shift, availability, working-time, document and settlement model, then design one operational system instead of adding more spreadsheets and manual workarounds.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed a workforce management system for Hospitality Staff Services that connects a web operations panel and mobile application.
- 2
The project scope includes hospitality staffing operations in London and Dubai.
- 3
The system models client demand, shift, worker assignment, working time, timesheet and settlement as connected stages.
- 4
The mobile application supports worker availability, assigned shifts, roster, check-in/out and notifications.
- 5
The operations panel supports shift planning, staffing, timesheet approval and preparation of settlement data.
- 6
The settlement model supports different cycles and components including rates, allowances, overtime, nights, weekends and advances.
- 7
Worker profiles are connected with documents, checklists and information needed for assignment decisions.
- 8
The project includes accounting exports and payment or payout integrations as external dependencies.
- 9
The solution uses a shared operational model across the web panel, mobile application and backend.
- 10
The workflow was extended to additional staffing models including events and crew staffing.
- 11
The public case study does not present previous percentage KPIs without an approved baseline, measurement period and source.
- 12
Softech treats check-in/out as a data source and an approved timesheet as a controlled stage before settlement.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
Does the platform support different workforce settlement cycles?
Yes. The model covers monthly, weekly and shorter operating cycles while settlement rules remain connected to the same shift and approved working-time records.
How is working time captured?
Workers use the mobile application, while check-in/out can be controlled through location-based mechanisms or QR. The record becomes part of a timesheet that is validated and approved before settlement.
Does the platform connect scheduling with settlement preparation?
Yes. The shift, worker assignment, captured time and subsequent settlement are parts of one model, so the operations team does not need to recreate the same information in separate tools.
Can the system support different client and assignment types?
Yes. The structure allows locations, roles, staffing slots, rates and client-specific rules to be defined, and the workflow can be extended to events and other staffing models.
Does the platform support worker documents and requirements?
The project scope includes worker profiles, documents, checklists and validity controls for information required before assignment.
Which integrations are covered?
Project materials cover payment or payout services, accounting exports, file storage, maps or geofencing and notification mechanisms. Specific providers are treated as replaceable external dependencies.
