Shyftplan

How a plan gets built across locations, roles and qualifications — templates, staffing requirements, forecasting from sales or occupancy, and whether the product proposes a roster or only draws one.

0 — A shared calendar of shifts; no templates, no roles or qualifications, and no notion of how many people a shift needs.

3 — Shift templates and a weekly grid per location, with roles attached, but staffing needs and qualifications are the planner's memory rather than the system's.

5 — Templates, roles and qualifications, staffing requirements per shift, open shifts, multiple locations and departments, and coverage gaps shown before publication.

8 — Demand-based planning from a named data source (POS revenue, footfall, occupancy or bookings), automatic roster proposals the planner can accept or adjust, labour cost shown against budget while planning, and cross-location staff sharing.

10 — Planning closes the loop: forecast, proposed roster and actual hours compared in one place, the proposal explains which rule or demand figure drove each assignment, and the vendor documents the forecasting method rather than calling it AI.

Whether the roster knows the rules it is subject to — ArbZG rest periods and maximum hours, youth and maternity protection, Minijob earnings limits, Tarifvertrag and works-agreement rules, surcharges — and whether it enforces them, warns, or leaves them to the export.

0 — No working-time rules described anywhere; the pages mention no check on daily hours, breaks or rest periods.

3 — Compliance is claimed as "supported" but the pages name no specific rule, or only a generic overtime warning exists.

5 — Named checks for the ArbZG daily maximum, the 11-hour rest period and breaks, plus a Minijob earnings warning, shown to the planner before publication; whether the check blocks or only warns is stated.

8 — Configurable rule sets per contract or employee group covering Tarifvertrag surcharges (night, Sunday, holiday), time accounts, youth-protection limits and works-agreement rules, with the planner's override of a violation recorded and reasoned.

10 — The rules are modelled as law, not as warnings: maintained rule sets for named collective agreements, sector-specific exceptions (care, hospitality) documented with the statute they rely on, every override attributable, and published guidance mapping each feature to the provision it serves.

What the employee on the shop floor actually gets: a mobile app to read the roster, enter availability, request and accept swaps, claim open shifts and clock in — in their language, on their own device or a shared one.

0 — No employee access; the roster is printed or sent as a PDF.

3 — A read-only app or web view of one's own shifts, with changes still requested by phone or chat.

5 — Mobile app with availability entry, absence requests, shift-swap requests with manager approval, open-shift claiming and push notification of changes.

8 — Swaps and open shifts resolved under the rule set (qualifications and rest periods checked before approval), clock-in by app or shared terminal with offline handling, multilingual interface, and team communication that keeps shift talk out of private messengers.

10 — Self-service is designed for people who never open a laptop: swap and cover flows that resolve without a manager where the rules allow, accessibility and language coverage stated, use on a shared or personal device both supported, and employees able to see and export the data held about them.

Whether the product can be introduced under co-determination (BetrVG § 87) — role-based visibility, what is logged, which monitoring can be switched off, retention of availability, absence and location data — and whether the vendor supplies what a works agreement needs.

0 — No roles or visibility settings described, no statement of what is stored, logged or retained, and GPS or activity tracking presented without any mention of switching it off.

3 — Basic admin and employee roles exist, but visibility of absence reasons or location data is not configurable and retention is unstated.

5 — Configurable roles limiting who sees whose data, GPS and similar tracking optional and off by default or stated as switchable, a published DPA, and a retention or deletion statement for employee records.

8 — Fine-grained visibility (absence reasons hidden from colleagues and line managers where not needed), an audit log of who viewed and changed an individual's data, configurable deletion periods, and documentation the vendor offers for works-council approval.

10 — Data minimisation is designed in and evidenced: a model works agreement or feature-by-feature data inventory published, no performance or behaviour scoring of individuals, monitoring functions individually deactivatable, and deletion executed automatically per configured period.

How planned and worked hours, surcharges and absences reach payroll — DATEV, Lohn und Gehalt, the tax adviser — and how the roster connects to the POS, HR and time systems a shift business already runs.

0 — No payroll path and no integrations; the month leaves as a spreadsheet someone retypes.

3 — Generic CSV export said to suit payroll, with no named payroll system and no surcharge handling.

5 — A named payroll integration or documented export (e.g. DATEV Lohn und Gehalt or LODAS) covering hours, absences and surcharges, plus at least one named POS or HR integration.

8 — Vendor-maintained payroll integrations with a lock step before transmission, wage types mapped per surcharge, POS integrations feeding forecasting, an HR master-data sync, and a documented API.

10 — Payroll is designed for, not exported to: several named payroll systems maintained, retro corrections after the close handled, the tax adviser given scoped access, and a versioned public API with webhooks and a deprecation policy.

Where the employee data lives, who the contracting entity is, who the subprocessors are, and whether that is documented rather than assumed. Independently sourced by the sovereignty pipeline; weighted seriously here, because a scheduling tool holds availability, absence and often location data about employees who had no say in the vendor.

0 — Non-EU vendor and contracting entity, hosting region unstated or non-EU, subprocessors not named.

3 — EU hosting offered as an option or claimed without a provider, while the contracting entity is non-EU or the subprocessor list is absent.

5 — EU hosting as standard and an EU contracting entity, but the subprocessor chain (messaging, push notification, analytics, support) includes non-EU providers without an explained safeguard.

8 — EU or DACH hosting with a named data-centre provider, EU contracting entity, full subprocessor list published, and any non-EU processing — push notification services included — named with its legal basis.

10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor in the EU, certification published, and a DPA that covers the employee data the app collects on personal devices.

Whether a buyer can compute the real annual invoice for their headcount and locations — including the time clock, payroll export, forecasting and other modules sold as add-ons — from public pages alone.

0 — No public prices at all; every tier is a sales conversation.

3 — A per-employee headline exists, but which features sit in which tier, the add-on modules, or a minimum seat or location count are unpriced or unmentioned.

5 — Per-employee or per-location prices public for the main tiers with the billing period stated, but at least one commonly needed piece (time clock, payroll export, forecasting, terminal hardware) is an unpriced add-on.

8 — Every tier and add-on priced publicly with the per-employee maths, how inactive or seasonal staff are counted, minimum term and VAT treatment stated; only genuinely custom work lacks a number.

10 — Complete price computability: a calculator or table producing the annual invoice for a given headcount, location count and module selection, including hardware, onboarding and renewal terms.