ProSchedule User Manual

ProSchedule helps manage shift work in restaurants: building employee and manager schedules (including automatically), tracking actually worked time, measuring planning accuracy and cost of labor. All of it rests on reference data and rules that are configured once and apply to the whole organisation (the "Admin" block), and on the settings of specific stores (the "Overview" block).

The manager web app and the employee's web cabinet open on the same sign-in page: the logo and a globe button for the language (Русский, English, עברית, O'zbekcha) on top, the form in the middle. The language can be picked before signing in and is remembered in this browser; in Hebrew the page lays out right to left, while addresses and codes stay left to right.

Signing in with a code. Enter your work email in the Email field and press Send code. A one-time code arrives by email, and the form switches to the Enter the code step showing the address it went to; the Edit link goes back to the email. The code is checked as soon as the last digit is in (or with the Verify button). If it is wrong, Invalid code appears under the slots and you can type it again. A two-minute countdown runs under the slots; when it ends, OTP expired and a Resend code link appear. Codes are sent by email only — there is no sign-in by phone number.

Telegram, Apple and Google. Under the form, after the or line, are buttons to sign in with Telegram, Apple and Google: icons with the tooltips Sign in with Telegram, Sign in with Apple and Sign in with Google (when there is only one way, it is a wide button with that label). A button appears only if your administrator enabled that way on your server, so the set of buttons can differ between servers. The service only confirms who you are; the server then looks for your employee card: for Google and Apple the confirmed email address must match the e-mail on the card exactly, for Telegram the username must match the login. These buttons never create accounts.

If sign-in does not go through, the reason is shown above the form:

• No employee card matches this account — a code or Telegram confirmed an address or name that no card has; after Google or Apple the message names the confirmed address and suggests signing in with a code or asking the administrator to add that address to your card;
• This account has no access to the manager app. Contact your administrator. — the card exists, but the employee's role works only in the schedule; such employees sign in to the web cabinet;
• Apple hides the address ("Hide My Email") — Apple's temporary address will not match a card: in your Apple Account settings stop using Sign in with Apple for ProSchedule, then sign in again and choose "Share My Email";
• the service did not answer or sign-in was cancelled — the page suggests trying again or signing in with a code.

Password sign-in is in the employee's web cabinet. The Sign in with password link above the email field switches the form to the Email, phone or employee ID and Password fields; the Sign in with a code link switches back. The Forgot password? link emails a link for a new password — the same as in the mobile app.

The system is built as a planning pipeline. Reference data and standards set the rules: structure — where people work; team and roles — who and with which permissions; deployment and ideal structure — how many people are needed at a given sales volume; shift types — which shifts managers work; general settings — by which rules everything is calculated. The daily processes — schedules, time tracking and reports — run on these rules.

The manual consists of blocks. The "Admin" block follows the order of the section's tabs — from "Team members" to the parameter-by-parameter walkthrough of the "Settings" tab. The "Overview" block describes the settings of a specific store. The "Employee schedule" and "Manager schedule" blocks — the daily work with the weekly and monthly schedules, "Shift" and "Time sheet" — fact hours, "PPR" — the stores' team makeup. The "Dashboards" block will follow. For each parameter you will find:

• what it is — its purpose in plain words;
• how it works — the mechanics: when the system reads the parameter and what exactly it does;
• what it affects — tags of the affected modules: Auto-scheduling Schedule editor Time sheet and others.

Value limits in the cards (min/max/step) match the field constraints in the interface. Screenshots are reproduced schematically: the layout and labels match the real screen, the data is sample data.

On the right of every page header, between the Admin gear and the avatar, sits the Notifications bell. The red dot on it is the number of unread notifications (more than 99 shows as "99+"). Pressing it opens the panel straight on the Unread tab; there are three tabs, each with its own count:

• All — the inbox: everything not yet archived, unread and read alike;
• Unread — unread only;
• Archive — what you archived. The archive is kept apart from the inbox: however many notifications pile up in it, they never push the current ones out and never count on the bell.

A notification row shows the type icon (with a dot while unread), the type name, the details (store, week, employee names), how long ago it arrived and, when there is somewhere to go, a View button that opens the related schedule or PPR page. The check mark at the end of the row is Mark as read; only unread rows have it. The two buttons in the panel header act on everything at once: Mark all as read (disabled when there is nothing unread) and Archive read, which moves every read notification from the inbox to the Archive tab (disabled while the inbox holds no read notification). An empty tab says No notifications yet.

Which notifications arrive, and to whom:

A notification is addressed to a person, not a position: every recipient has their own "read" mark and their own archive. Recipient lists are built at the moment of the event from the current roles and structure; which roles are notified about fact shifts is set in the role's "Notification parameters" dialog.

The first button on the right of the header switches the appearance: the moon turns on Dark theme, the sun brings back Light theme (the button's tooltip says the same). The choice is remembered in this device's browser — on another computer or phone the theme is chosen separately; until it has been chosen, the page is light. Status colors in the dark theme are the same as in the light one, only softer and lighter so they stay readable on the dark background.

On a phone or a narrow screen (a tablet, half a monitor):

• the sections, Admin and User manual are gathered in the ☰ menu on the left of the header; the theme, the bell and the avatar stay on the right;
• windows slide up from the bottom as a sheet (large ones take almost the whole screen); they close with the cross in the corner or the Close button;
• wide tables scroll sideways inside their card; in the team, time sheet, PPR and manager schedule tables the name column stays in place as you scroll;
• the filter bar above the page is not pinned and scrolls away with the page, freeing the screen for the data;
• in the day grid shifts are drawn and moved with the mouse, so on a phone a shift's time is set with the clock button on the employee line — the Shift parameters window.

When there is nothing to show, a grey card with an explanation stands where the table would be — no header row of an empty table above it. There are two cases:

• there is no data yet — the card says where the data comes from and, where it can, leads to the place it is entered (for example, Go to the team on the "Action plan" tab or Update store team in an empty managers schedule). Filters and bulk buttons are hidden then: there is nothing for them to narrow;
• there is data, but a filter or search found nothing — the filters stay, and the Nothing found card has a Reset filters button. This is how the timesheet, the reports, "Corrections", PPR and the admin tabs work.

A link to a deleted or non-existent schedule opens the Schedule not found card with a Go to Overview button.

The section is visible only to users whose role has the Is admin permission enabled (configured on the "Roles" tab, see the chapter on roles). Such users see the Admin item in the main menu; the section's direct path is /admin.

Inside, the section is laid out as a vertical tab menu on the left and a working area on the right. On small screens the menu collapses into a dropdown at the top. The system remembers the last opened tab and brings you back to it on your next visit.

The tab heading on screen is Team members, with the description "A list of all the employees in your structure showing their Name, Email, Structure path and Role" below it. Each row of the list is one employee; clicking a name opens their card.

The card opens by clicking an employee (heading Team member profile) or via the "Add team member" button (heading Add team member). Changes are applied with the Save button — one of the few admin screens with an explicit save.

The primary unit is picked in a field with search across structure nodes; the selected path is shown as a chain of blue chips. "Custom structure" is a list of additional units the employee also belongs to (for example, to give a supervisor access to several regions); these links are not overwritten by integration and are added with the "Add" button.

Personal scheduling limits (visible when editing an existing employee). If a personal value is not set, the general one from the "Settings" tab applies:

• Min shift duration (hours) and Max shift duration (hours) — personal shift-length bounds for auto-scheduling (step 0.5 h).
• Max working hours per week — a personal weekly limit; the auto-scheduler will not exceed it, and exceeding it manually raises the "Weekly hours limit exceeded" alert.
• Days when scheduling preferences should not be considered — on these weekdays the employee's schedule preferences are ignored by the scheduler.
• Restricted workdays list — a hard ban: on these weekdays the employee is never scheduled at all.

The employee's personal rate for cost-of-labor calculations, with a change history. An entry is added with the Add rate entry button: the Effective since date, the Rate value and the Monthly rate (salary ÷ month hours norm) checkbox. For each date the latest entry dated "no later" than it applies. If "Snap 'since date' to the 1st of the month" is enabled in settings, the date of a new entry automatically becomes the 1st. If there is no personal rate, the role rate applies, then the default rate (see Cost of labour calculation).

When Employee integration is on ("Settings" tab → "Integration"), employee data comes from an external HR system. So that manual edits do not conflict with synchronisation, some card fields are locked. Each "Is it possible to change…" toggle in the integration settings unlocks its field; its value is then not overwritten by synchronisation:

The tree has two kinds of elements. A node (blue circle with an arrow) is a structural unit of any level: a region, a city, a division. Nodes expand on click and can contain nested nodes and stores. A store (grey circle with a shop icon) is an end point: it never has nested elements. On the right of each row is the employee count of that unit. The expanded/collapsed state of the tree is remembered.

• Add — the Node and Store buttons at the end of each level. The "Store" button becomes unavailable when the plan's store limit is reached.
• Rename — clicking the name opens the card ("Node" or "Store") with the Unit name field; changes are applied with the "Save" button. The key (identifier) does not change on rename.
• Move — drag the row by the ⠿ handle and drop it on the new parent. While dragging, invalid targets are dimmed: you cannot drop an element onto a store, onto itself or into its own descendants. While you drag a non-top-level element, the Drop here to move to root zone appears at the top.
• Delete — in the node/store card, in two steps ("Delete" → "Are you sure?" → "Approve"). Child elements are not deleted — they move one level up, to the parent of the deleted node.
• Team makeup — the node card shows the "Supervisors" list (for a node) or "Team" (for a store); clicking a person opens their "Team member profile". The makeup is changed through the employee card (the "Structure" field), not from this dialog.

The screen is a table of roles with instant saving (there is no separate "Save" button). In each row, left to right: the role's color mark, name, the "Role rating" range, and four action icons: job titles (briefcase), access parameters (gear), notification parameters (bell), delete (trash); the ▲/▼ arrows change the order of roles in lists. The Add role button creates a role named "New role" — rename it right away.

The gear in a role row opens the "Access parameters — ‹role name›" dialog. Every checkbox saves immediately. The groups, top to bottom:

Role rate — the hourly cost for employees of the role who have no personal rate: enter a number and pick the /hr or /mo unit (a monthly salary is automatically converted to an hourly rate by the month's hours norm). The "Clear" button removes the role rate — then the "Default hourly sale rate" from settings applies.

Time sheet approval level — "No", "Level 1", "Level 2" or "Level 3". The time sheet is approved level by level, bottom up: each next level closes editing on the previous ones. A role can approve the time sheet only at its own level; a rejection at an upper level removes the approvals of the lower ones.

The bell in a role row. Four checkboxes define which notifications the role's employees receive: "Notify about employee shifts" and "Notify about manager shifts" (in-app notifications about fact shifts that need approval) and their email variants "Notify by email…". Notifications go only to users of roles with the checkbox enabled. Where these and all other notifications are read — see "Notifications: the bell in the header".

The briefcase in a role row opens the "Role ‹name› — job titles" dialog. It links job titles from the HR system (for example, "Grade 3 Cook") to ProSchedule roles:

• The right column "Job titles" — all job titles not yet linked to a role; a click links one.
• The left column "Assigned job titles" — the linked ones; clicking a name unlinks it.
• Sets by default — a new employee with this job title gets the role automatically when loaded from integration. In the "By certifications" mode, a role bound to a certification is assigned by the integration only to an employee holding a valid certification for it; otherwise the job title's next available role is assigned.
• Training only — if an employee with this job title is given such a role, their "On training" status turns on automatically (it cannot be removed manually while the role is "training only"). In the "By certifications" mode the status of employees (not managers) is set by certifications, and this rule does not apply.

A position is a workplace in the schedule: "Cashier", "Kitchen", "Delivery assembly". Each position has a ladder of "sales volume → employee count" steps. For every half-hour slot of the day the system takes that slot's revenue forecast, finds the highest step whose threshold is reached — and gets the recommended number of people on the position. The sum across all positions is the "recommendation" the actually staffed schedule is compared against (that is how accuracy is computed). Ladder steps are stored sorted ascending by threshold.

The gear opens the "Settings — ‹position name›" dialog. All changes are saved immediately.

• Revenue measure — what the ladder is measured in: Sales (money; divided by the store's price coefficient), Transactions (receipts) or Menu items (dishes).
• Order chanels — which channels "feed" the position. For example, a "Delivery assembly" position makes sense to size only from delivery channel revenue. An empty selection means "all channels".
• Store concepts — in stores of which concepts the position exists. A position without a single concept will not appear in any store.
• Based on weekly revenue — switches the position to "budget" mode: instead of an hourly people recommendation you set hours per week from weekly revenue. Such positions do not take part in the hourly recommendation and do not affect the staffed-vs-recommended chips.
• Does not impact SPMH/TPLH — the position's hours are excluded from the SPMH/TPLH productivity metrics.
• No certification required — on by default. Turn it off to make the position require a certification in the "By certifications" mode: auto-scheduling places on it only employees with a confirmed certification, and when anyone else is placed manually, the schedule flags it with the "No certification for the position" warning.
• Time window — the period of the day the position's recommendation is calculated for; outside the window the recommendation is always 0, even if the ladder's baseline step implies people at zero revenue. Every calculation respects the window: the schedule editor, auto-scheduling, dashboards, the budget and "Analyse actual schedules". Two time fields "from — to"; the window is saved once both are filled, the X button clears it. Empty — the recommendation is calculated over the whole day.
• The step ladder — up to 7 steps; the top row is the employee count (or hours in "budget" mode), the bottom one is the revenue threshold. The "+" and "−" buttons sit next to the section heading: "+" adds a step on the right and is disabled at the seventh step, "−" removes the last one and is disabled once a single step is left. When the steps do not fit the window, the table scrolls sideways.

The deployment is versioned. The active version (marked "Active") is the one the admin section is editing right now and all calculations read: auto-scheduling, dashboards, budget. Selecting another version in the list activates it instantly; the previous one is kept as a snapshot you can return to. The active version cannot be deleted — activate another one first.

Analyse actual schedules is a way to build the deployment "from real life": pick a year and a week, drag finished store schedules into the "Selected" column (or simply click or tap a schedule — it moves to the other column, which is handier on a phone) and press "Analyse". The system reconstructs the ladders from how people were actually staffed in those schedules and saves the result as a new active version (thresholds are fitted to the peak simultaneous headcount at the corresponding demand). The previous version remains — the operation is fully reversible. Positions that were never filled in the selected schedules are zeroed out; "budget" positions are skipped by the analysis.

The tab has four sections: Ideal structure, HR statuses, Certifications and PPR settings. The "Certifications" section is always open. In the "Simple" mode certifications restrict nothing: they feed the PPR statistics and the expiry reminders — a banner above the table points this out. The system remembers the last opened section.

The store team standard: how many managers and what team mix a store needs depending on sales and working hours. Every concept from "Settings → Store concepts" gets its own table of tiers here — concepts appear automatically, and the Concept filter leaves just one on the page. A table row is "Tier N"; the columns are:

• Monthly sales from and Open hours a day from — the tier's thresholds;
• Branches — how many stores currently fall into the tier; a click opens their list with average sales and working hours;
• Managers, people — a column per role with the "Used in managers schedule" checkbox: how many people of this role the store needs;
• Team mix, % — a column per employee role (a role used in the employee schedule but not in the managers schedule) plus the "Trainee" column. The percentages set the minimum share of the whole employee team, trainees included. 0 % means no minimum — any number is fine. The sum is at most 100 %.

How a store falls into a tier. The store must clear both thresholds; of the matching tiers, the one with the higher sales threshold is taken, and on a tie — the one with the higher hours threshold. Sales are the average monthly total of the store's sales forecast; hours are the widest opening window of the store, or 12 if no opening hours are set. The first tier starts from zero; its thresholds cannot be changed. Tiers are shown in ascending order of sales. Everything saves automatically; there is no "Save" button.

The catalog of statuses a manager assigns to employees on the store PPR page. Add the standard set creates five ready-made statuses — NEW "Newcomer", TRAINING "In training", PROMOTION "Promotion candidate", LEAVE "Long absence" and RISK "At risk of leaving"; they can be renamed. Add status creates your own. The status fields:

A status that is already assigned to employees cannot be deleted. Turn off its Active switch instead: the history is kept, and the status no longer appears in the picker.

The catalog of confirmed skills. Above the table there are two sub-tabs: Positions — certifications that admit to deployment positions, and Roles — certifications that open roles. A certification gives access either to positions or to roles — never to both at once. The fields of the Add certification dialog:

• Code, Name, Description;
• Never expires or Validity, months — the validity of a new certificate is counted from the certification date;
• Gives access — pick To positions or To roles, then tick below the deployment positions the certification admits to or the roles it opens. The kind of the open sub-tab is picked first; once saved, the kind cannot be changed, and the table moves to the new certification's sub-tab;
• Who can receive it — Applies to: everyone, managers or employees, the same as for HR statuses.

A role with no active certification bound to it is available to everyone by job title, as before. The "No certification required" checkbox is set in the position's settings: anyone can be placed on such positions.

Quick start — the ⋮ menu. On the "Positions" sub-tab: Create from the positions creates a never-expiring certification for every position that requires a certification and grants nothing to anybody; Grant from the current positions grants every employee the certifications of their priority positions from the card. On the "Roles" sub-tab: Grant from the current roles grants every employee the certifications that open their current role, dated today — it is handy to do this before switching to the "By certifications" mode, so that nobody loses access to their role. Running it again duplicates nothing.

Bulk granting — "Grant…" in the row menu. This is a one-time grant. The Roles and Stores filters narrow down the group of people (the employee's main store is what counts); without filters everyone qualifies. The dialog calculates right away: "Match the conditions" = "Already have it" + "Not applicable" + "Will be granted". Grant (N) grants the certificate dated today only to those who do not have it yet. It is not a standing rule: new employees will not get the certificate on their own — repeat the grant when needed.

Archive and deletion. Archive — the certification can no longer be granted, and it disappears from the pickers and from the store matrix; those who already hold it keep the admission. Show archive shows the archived ones, Restore brings a certification back into use. Delete (for an archived one — Delete permanently) is final: every granted certificate is revoked, and the dialog shows in advance how many there are. If you only need to stop granting it, archive the certification instead. A certificate already granted can always be renewed, even if its scope was narrowed later.

Automatic granting in the "Simple" mode. When an employee's role changes — manually or on a load from integration — the system itself grants them the certifications that open the new role. The certifications of the previous role stay.

All values save immediately.

The manager schedule is built not from positions but from shift types. The screen (heading "Shift parameters") is split into two blocks:

• Default shifts — four base day-part shifts: Morning, Middle, Evening, Night (icons: sunrise, sun, sunset, moon). They cannot be deleted and their order cannot be changed; the name, color and parameters — can.
• Additional shifts — created with the Add shift type button: stocktake, goods receiving, month opening/closing and so on. Their order is changed by dragging the handle on the left; deletion — the trash icon with confirmation.

In each type's row: a color mark (a 12-color palette — the shift is painted with this color in the schedule), the name and the settings gear. Changes are saved instantly.

The gear opens the "Settings — ‹name›" dialog. The fields by section:

• Short name — a compact label shown in the schedule cell (the full name is in the tooltip).

The "Availability parameters" section:

• Minimum store working hours — a default shift is required for a store only if its working day is no shorter than this value (for example, the Night Shift — only for stores working at night or around the clock).
• Shift accessible on holidays — if off, the shift is not required and not placed on holidays.
• Revenue measure and Minimum monthly — a store scale threshold: the shift is required only if the store's average monthly revenue in the selected measure (sales, transactions or menu items) is at least the minimum. The average is computed from the sales history over complete months; if there is no data for the selected measure, the restriction is not applied. 0 — no restriction.
• Store concepts — in stores of which concepts the shift exists.
• Roles — managers of which roles can work this shift (the list shows only roles with the "Used in managers schedule" flag).
• Main — the priority role for an additional shift: auto-scheduling first places a manager of this role on it, and if they are on vacation — the shift is not required that day.

The "Shift parameters" section:

• Shift start and Shift duration — the default time. The clock button by the start field switches to "Next day" (for shifts starting after midnight).
• Maximum number of shifts in a row — how many days in a row one manager can work this shift.

The "Repetition parameters" section (additional shifts only) — when the shift is required:

• Day — weekdays (Mon…Sun);
• Week — week numbers of the month (#1…#5), combined with weekdays: "every first Monday of the month";
• Month — "First day of month" and/or "Last day of month".

• Does not impact accuracy — makes the shift optional: its absence is not counted as an error and does not lower schedule accuracy. For a default shift this also means "not placed automatically — manual only"; an additional shift with this flag is still placed automatically, but last.

The "Change the look and feel of the app" section — two parameters.

The "Based on that settings we will auto-schedule your shifts" section. This is where the constraint rules live: the auto-scheduler picks shifts so as to cover the deployment recommendation without breaking any of these rules. Most rules also apply to manual editing — violations are highlighted with alerts in the editor.

A block inside the auto-scheduling section. Its core is the "break ladder" ("Break duration in minutes depending on shift duration"): a table of up to 5 rungs "shift hours → break minutes". For a shift, the highest reached rung is taken, and its minutes are deducted from paid hours — in schedules, the time sheet, reports and the employee cabinet (for roles with "Consider lunch breaks" enabled).

The "Configure time and attendance parameters" section governs the life of fact shifts — from the mark on the terminal to the row in the time sheet. Every clock-in/out mark goes through a processing pipeline; the parameters below are its knobs.

The "Default hourly sale rate, average labor tax ratio, and how since-date is normalized for new history entries" section. These parameters feed the "Cost of labor" (COL) report and all monetary metrics of the dashboards. The rate of a specific hour is chosen via the chain: the employee's personal rate → the role rate → the default rate (see the diagram in chapter 04).

"Restrictions applied to employees younger than the age threshold (derived from date of birth). When set, these take priority over the regular settings". The age is determined from the "Date of birth" field of the employee card — as of the current date, so on the day of majority the restrictions lift themselves.

"Configure different store concepts wich you have in your portfolio" — the reference list of formats: a classic restaurant, a food court, a mall unit and so on. Each entry is a pair: Store concept (name) and Store concept code (number); rows are added with the "Add store concept" button and removed with the trash icon.

The concept is the key by which a store gets its standards. It is used in four places:

• assigned to a store in the "Store Card" (the "Store concept" field);
• selects the deployment positions: a store sees only the positions of its concept;
• selects the manager shift types for the schedule;
• is the key of the tables in the "Ideal structure" section.

"Configure where customers can place their orders": dine-in, delivery, drive-thru, aggregators. The format is the same — a name and a code; the channel with code 0 is the base one and cannot be deleted.

Channels work in tandem with revenue and the deployment:

• each channel gets an hourly revenue distribution computed from sales history — you can see it on the "Transactions distribution" chart in the schedule editor;
• a deployment position can be "fed" only by the revenue of its own channels (the "Order chanels" setting in the position; an empty selection = all channels) — this is how "Delivery assembly" scales only with delivery orders;
• the revenue chart breakdown is built by channel.

"Configure your integration endpoints". The section joins two directions: synchronising employees from the HR system and loading sales (history and forecast) from the POS/analytics system.

Open the Overview page and pick a store in the list — three buttons appear in the header: Store (the "Store Card"), Team ("Team parameters", with the employee count on a badge) and Revenue (the sales forecast). Below is how each of the three windows works.

The Store button opens the "Store Card" window. Its header has four fields: Store name and Store ID (read-only: the name comes from the structure, the ID is the location's system key), Email and Store concept. Changes to the header and the "Open / close period" tab are applied with the Save button; the "Shifts" tab saves instantly on every change.

Available to users with the Open / close hours permission. Three blocks:

• Preparation and cleaning — "Hours needed to prepare and clean the store": Working hours before opening (from −6 to 6, step 0.5 — a negative value means the team starts only after opening) and Working hours after closing (0–12). An empty field = inherit the general settings (see the diagram above).
• Working hours by day of week — "Set the hours when the store is open and closed for customers": for every day the Since and Till fields (15-minute step; opening no earlier than 06:00; closing past midnight is entered with the "Next day" button — up to 06:00 of the following day) and the red Closed toggle.
• "Technically 24 hours working (only manager and technical staff needed)" — day-of-week buttons: on the marked days the manager night shift counts as needed regardless of the guest hours, and early clock-ins are not trimmed in time tracking.

Available with the Shift timing parameters permission — "Setup special timing parameters for each shift type". For every manager shift type of this concept you can override Shift start and Shift duration for this specific store (the second cascade level from chapter 07). A block without an override is shown semi-transparent — it inherits the shift type's values; the first change to either of the two fields creates an override for both at once. Saves instantly.

The orange Store login credentials button in the card header — "Credential to login to your store in ProSchedule Time Attendance application": the organisation ID, Store login and Password. The password is generated with the refresh button and is shown only once — generating it again invalidates the old one. Access to the window is granted by a separate service permission of the role.

The Team button opens a full-screen table of the store's employees (the roles that take part in the employee schedule or the manager schedule). There is no "Save" button here — every change is applied immediately. On top — a search (by name, "System employee ID" or "Additional ID") and the Add team member button (the "Can add new employees" permission); it opens the same card as in the admin (chapter 02) but without the "Structure" block — the employee is attached to the current store.

The table columns and what they do:

The Revenue button opens the store's revenue forecast by month. On top — the month picker (the next month by default), below — a table by day: Day, Sales, Transactions, Menu items (optional) and the computed AGC (average check = sales ÷ transactions). Weekend rows are highlighted orange; the month totals are at the bottom. Changes are applied with the Save button; editing the fields requires the Can edit revenue permission — including for data loaded by the integration.

The tools in the window header:

• Percent — the "%" field with an apply button: change all open days of the month at once (for example, +10% over last year's level); locked days stay as they are. Range −100…100.
• ⚡ "Auto generate revenue forecast" (the Can generate revenue forecast permission) — builds the month from sales history: the averages for each day of the week over the last two complete months, multiplied by this month's seasonal ratio from the two previous years. The result is saved immediately and replaces the open days of the month; locked days keep their figures. When the whole month is locked, the button is disabled. If the analysis period has no sales at all (for example, a new store has no history for the two months, or the chosen period has no data), the forecast is not generated: a message appears and the saved figures stay unchanged.
• ⚙ Analysis settings (the Can edit revenue permission) — the history period for generation and the source branch: a new location can build its forecast from a similar store's data. The period is past sales the forecast learns from, not the month to forecast: it must lie within the last year and end no later than today. Any other period is highlighted in red and is not saved. While a custom period is set, the settings button is highlighted in orange. "Reset to default" removes it, and the forecast is again built from this location's last two complete months, moving forward every month.

The forecast cannot be changed for days the plan is already working on:

• days outside the "Schedule history editing depth in days" — the same days the schedule editor locks. At 0 today is locked too;
• weeks whose employee schedule is "Approved" — until the week is returned to "Draft". The manager schedule does not affect the forecast.

The lock applies everywhere: to manual entry, to auto-generation and to integration uploads. That way the plan the schedule was approved against — and that SPMH, TPLH, COL and accuracy are calculated from — does not change after the fact.

In the Revenue window such rows are read-only. A lock sits next to the day number, and its tooltip gives the reason: "Outside the schedule editing depth" or "The employee schedule for this week is approved. Return it to draft to change the forecast". Above the table there is one line: "Days outside the schedule editing depth and weeks with an approved employee schedule are locked". If the week is approved while the window is open, saving shows "The forecast can't be changed for days outside the schedule editing depth or for weeks whose employee schedule is approved"; the locked days go back to their saved figures and the edits on the other days stay — press Save again. The manager mobile app works the same way.

The schedules of the selected store are listed on the Overview page — under the header there are two tabs: Linear employees (weekly schedules) and Managers (monthly schedules — the next block is devoted to them). The last seven weeks are shown by default; the Show last field sets the list length — from 1 to 99 weeks, so the history can be extended as well as shortened.

The Add new schedule button (the "Can edit schedule" permission) creates the week that follows the most recent existing one. An arbitrary week — a past one, or a future one further ahead — is opened from the editor: pick it in the week selector, and if there is no schedule there yet, a "No schedule" placeholder appears with a create button.

If you are building a schedule for the first time, the route is short: create the week → enter the preferences → run auto-scheduling → finish the days by hand → submit and approve. Each step has its own chapter, and the whole route is assembled in the "Build a week from scratch" walkthrough.

• Outside the draft the editor is closed: the grid is visible but not editable, the whole toolbar goes dim; only "Return to draft", "Approve" and printing are available.
• Printing is unlocked by approval — or in advance, by the "Allow print schedule before approval" setting.
• The personal cabinet shows employees planned shifts only from an approved schedule (the "Employees see only approved shifts" setting, on by default): upcoming days of an unapproved week are hidden in the cabinet (shown as "Awaiting approval"), past days stay visible.
• Editing depth: days older than the "Schedule history editing depth in days" are locked forever — both in the grid and in the day tools; week-level commands (auto-scheduling of the week) work on the remaining days.
• The sales forecast of an approved week is locked — for manual edits, generation and integration alike. To correct the forecast, return the week to "Draft" (see locked forecast days).

At the top — the store and week selectors (switching the store opens the same week of its schedule), below — eight tabs: seven days (from the "first day of week" date in the settings) and Week. There is no separate "Save" button: every action is saved immediately, and it is backed by Undo / Redo — up to five history steps per day.

The icon's colour says what the button will do. The amber bolt ⚡ is automatic generation, as everywhere else in the product (the revenue forecast generator, setting the fact from the schedule): one press rewrites what you had placed. Blue opens the windows that feed the schedule and works on the roster. Red throws work away. The three lifecycle buttons wear the colour of the status they move the schedule to — the same colours as the status chips on "Overview": Draft ✎, Submited ✈, Approved ✓. Print, Undo and Redo change no status and stay grey.

By default the hourly distribution is computed from this store's own sales history over the five weeks before the schedule's week. The "Transactions distribution" dialog can change that: pick a store and a period, then press "Analyse" (the download icon next to the calendar).

From then on the whole week — the chart, the hourly recommendation, the accuracy and the peak hours — is computed from the chosen store's curve over the chosen period. The source currently in force is shown under the filters; "Reset to default" (the arrow) returns the calculation to this store's own five weeks.

The period must cover between 7 and 366 days — anything shorter than a week would leave some weekday with no data at all. While the period is outside those bounds the analysis button stays disabled.

Only the pointer to the store and the period is stored, not the numbers themselves: upload sales for the same period later and the schedule picks them up without re-running the analysis. Permissions are the same as for editing the schedule.

An "employees × days" table: the cells hold shifts like "Cas: 09:00 – 18:00" (underlined with the position color; the leave time is shown per the half-hour convention), the last column holds the Total of hours for the week, the day headers — a people counter. Two sortings — alphabetical and by positions (in groups); the chosen sorting also sets the format of the "Week summary" printout. A red "Vacation" cell is an absence period. Preferences are visible under the shifts: clicking a working preference places it as a shift on the employee's main position. The "i" button opens Schedule statistics — the weekly KPI tiles and two charts: "Team rating/Accuracy" by day and "Positions split" ("Need for position" from the recommendation against "Availability in the team" by trained staff).

If nobody is on the store team or on this week's shifts, the table is replaced by the No team members yet card.

• Create — press the mouse on an empty cell and drag: the shift takes the range. With Shift held, a second segment is added to an existing shift (a gap within the day).
• Move — drag the middle of the shift; resize — drag the first or the last column (arrow cursor).
• Set the exact time — the clock button on the line: "Shift start" and "Shift end" with a 15-minute step (a past-midnight end is entered as next-day time). A time that lands on unavailable hours will not be saved: "Selected time overlaps unavailable hours".
• Yesterday's shift tail (past midnight) is shown as a light-blue shadow at the start of the grid and is not editable from here.

Grey (hard) hour locks: a forbidden weekday or an absence period; the night window for those who may not work at night; half-hours already taken by this person on another position, in the manager schedule or by yesterday's shift "tail" — adjacent shifts may not touch each other. Pale cells are the soft "outside the preference" mark (with the preference display enabled); a shift over such a cell is highlighted pink but not forbidden.

A red name — the line has a conflict: a shift on a blocked day or an absence period, night hours without the night-work permission, or the personal weekly hour limit exceeded (the "Weekly hours limit exceeded" hint also shows the limit itself). Hover the name to see the reason.

Hard hours limits (the checkboxes in "Time and Attendance"). A shift does not stretch past the employee's remaining hours: the bar simply stops growing. In the "Shift parameters" window, on an overrun, a red line "Available under the limit: … h" appears under the fields and Save is disabled. The day's remainder is visible in the hint on the hours total next to the name. It is computed from the fact hours through the last fact shift and the planned hours after it — across all stores and the manager schedule. Shortening a shift is always allowed. If an edit still reached the server with an overrun (for example, the hours changed in parallel), it is cancelled with the message "The shift exceeds the employee's daily hours limit" ("…weekly hours limit", "…monthly hours norm"); an "Undo" step of the history that would bring back hours above the limit is not executed either: "Cannot undo: the restored shifts would exceed the hours limit".

The "+" button at the end of every position opens the Add employee to position window. By default it shows the store team: the "Name", "Positions", "Schedule preferences", "Hours" columns for the week; the Only not added and Only for current position switches narrow the list. The search above the list matches the name, the "System employee ID" or the "Additional ID", both for the store team and when searching other stores. Those already standing on another position today are marked "Already in schedule", yet can be added — a shift may be split between positions. Turning off From current store, you search other stores: only an employee with the "Available for shifts in other branches" flag can be borrowed (without it — a red ban).

The panel above the grid: the day's "Revenue", SPMH/TPLH (forecast against deployment), "Hours" (placed / recommendation), "Non-cust. hours" (a pair as well: placed / by the ideal deployment — the hours outside the open-to-guests window, that is the preparation and cleaning), "Training" (in orange — trainee hours), "Accuracy" (green once the minimum is reached), "Pick hours security" and "Team rating" by day parts (morning/day/evening/night against the "Team score goal"). On the right — the day chart: the "Team" fill (people per hour) and the "Transactions" line from the sales history.

All the limiters are described in the auto-scheduling settings: shift length, the hour and consecutive-day limits, rest between shifts, the night window, positions and universal workers, the underage rules. Hidden employees, trainees, absentees and those busy in other stores are not placed. After the run the "Scheduling insights" button appears with hints — for example, who was missing and why. The scheduler respects the hard hours limits too: whoever has less remainder than a minimum shift is not placed on the day, saved default shifts that do not fit the remainder are skipped, and if after the placement someone's hours still went over the limit — it shortens the shifts it placed itself. Both cases land in "Scheduling insights": "Shifts shortened by the hard hours limit (…)" and "Hard hours limit (…): … — the hours left are less than a minimum shift, so auto-schedule did not place them". Auto-scheduling now always applies the underage restrictions rather than only highlighting them in the grid.

Three preference tools — do not confuse them:

• Schedule preferences — the table where the manager enters and edits the team's preferences for the week;
• Add only employees with schedule preferences — adds the empty lines of those who asked to the day;
• clicking a preference in the week summary — turns that particular preference into a shift.

Employees leave their preferences in their own cabinet; the days on which preferences are ignored are set in the employee card.

The scheduler computes the week without locking it and saves the result in one go. If someone changed a day of the week in the meantime, the save is cancelled with the message "The schedule changed during auto-fill — run it again" — just start it again.

The route for a new manager — from an empty week to an approved schedule:

1. Create the week: "Overview" → the Linear employees tab → Add new schedule. Open it with the "Edit" button.
2. Collect the preferences: the Schedule preferences button — verify and complete what the team left in their cabinets; "Apply".
3. Run the week's auto-scheduling: the Week tab → ⚡ Auto schedule. The scheduler closes the recommendation honoring the preferences and the constraints.
4. Read the "Scheduling insights" 💡 — the scheduler itself tells you where it ran out of people and why.
5. Walk every day: remove the brick "+" and sand "−" on the position strips (drag or draw shifts), sort out the red names, add people with the "+" on a position if needed — including from another store.
6. Check the breaks — the fork blocks should not land on the peak hours; they are dragged with the mouse.
7. Verify the "Day analysis": every open day's Accuracy is at or above the minimum, the "Team rating" is green across the day parts, the "Team/Transactions" chart has no dips on the peaks.
8. Submit and approve: ✈ Send for approval, then — whoever holds the permission — ✓ Approve. After approval, print: 🖨 "Week summary" or "By day schedule".

ProSchedule has a mobile app — ProSchedule — for iOS and Android: the mobile version of the whole platform. It has two modes: the employee's personal account (hours, shifts and preferences, as in the web cabinet) and manager mode (store overview, the day's shifts, the dashboard and settings, as in the manager web app). A two-position switch in the top bar, opposite the avatar, moves between them: the briefcase icon is Manager, the person icon is Personal account (these are also the names assistive technologies announce; the switch itself is Mode). The floating tab bar at the bottom shows only the current mode's tabs. The chosen mode is remembered on the device: the next launch opens in the same mode.

The personal account has three tabs and the profile:

• Overview — monthly worked-hours rings: plan, fact and goal; the Hours goal field is editable right on the tab.
• Schedule — a full shift calendar with three switchable views: "Day", "Week" and "Month", plus a collapsible month calendar on top. Scheduled and actual shifts appear as colored blocks; tapping a shift opens its details. In the "Month" view, tapping any day that has shifts opens a list of all that day's shifts. If "Employees see only approved shifts" is on in General Settings (it is by default), upcoming shifts from an unapproved schedule are not shown here — such days are marked "Awaiting approval".
• Schedule preferences — the weekly preference editor: "from … to …" times, a Day off toggle, overnight shifts past midnight. The "Month" view is a month calendar marked with each day's preference (its start time, or "Off"); the selected day is edited in the card below the calendar.
• Profile — opens by tapping the avatar in the top bar: the employee's details, the language picker (Language), the appearance choice (Theme: Light, Dark or System — the theme is chosen only here; the top bar now carries the mode switch in its place) and the Sign out button. Every signed-in user can set a profile photo here (Add photo / Change photo — the picture is cropped to a square and shows in the web cabinet too), and manually added team members can permanently delete their account with the Delete account button — in the confirmation dialog the Hold to delete button must be pressed and held.

Manager mode. Not everyone sees the mode switch. Users with a separate administrator account always do; team members signing in with their own employee card only if their role is not limited to the line-staff schedule — the role either takes no part in the employee schedule or takes part in the manager schedule. It is the same rule the manager web app applies at sign-in. Stores and structure nodes appear within the scope assigned to the account. The Admin tab exists only for roles flagged as administrator. Manager mode has four tabs:

• Store overview — the top bar, next to the store selector, carries two icon buttons: Store Card and Team (the second one shows the head count). They open the same two windows as the buttons in the header of the web "Overview" page (see below). The tab itself holds the Recent schedules block with an Employees / Managers switch — for every week (or month, for managers) its accuracy in percent (green when not below the minimum from the settings, red otherwise) and status: Draft, Submited, Approved or Not created. Creating, opening and deleting schedules stays in the web version.
• Shift — the selected day's shifts (the counterpart of the web "Shift" page): the top bar carries the date, the store selector and one-day back/forward arrows with a return-to-today button. On top, the day's KPI tiles: Revenue, SPMH, TPLH, Hours and Compliance (fact / plan and the difference), then the Data on stamp with the calculation time. Below — a search field (by name, "System employee ID" or "Additional ID") and the Managers, Employees and No schedule groups: each person shows their position, the scheduled time and the actual clock in/out, "fact / plan" hours, a Break line when break placement is enabled, and the fact-shift status icon (a check mark — Approved, a question mark — Awaiting approval, a cross — Not approved). A shift recorded with zero hours by the hard limit is marked with a red cross and the hint "Shift started after the limit was reached — recorded with zero hours", a cut one — with the scissors "Shift cut at the hard hours limit". In the personal cabinet (on the phone and on the web) such a shift is shown with the mark "Daily hours limit reached" (weekly limit, monthly norm) and zero hours, a cut one — with the mark "Shift cut at the hard hours limit". Tapping a row opens the person's card: Schedule, Clock in/out, Hours, the list of scheduled periods and every fact shift with its editor, edit time and comment (archived ones dimmed). Shifts cannot be opened, closed, edited or approved from the phone.
• Dashboard — one week of KPIs (the week boundaries follow the first day of week from the settings; the date range is shown in the top bar). The bar holds the structure node selector (Structure: the chain of parents and the child nodes available to you; the Back arrow goes one level up) and one-week back/forward arrows with a return to the current week. The settings card: the Comparison row picks what is compared with what — Forecast vs Deployment, Fact vs Forecast or Fact vs Deployment; the Include not approved shifts switch adds shifts still awaiting approval to the fact. Below — the selected node's KPI tiles (Accuracy, Hours, Non-cust. hours, SPMH, TPLH, IPLH, COL, Hours used, Sales with a Transactions sub-line, Training hrs; IPLH and Hours used only when there is data behind them) with the reference value and the difference, and the Structure list: one row per child node with hours, accuracy and status (the schedule Status for a store, Statuses — the approved share — for a group); tapping an available row drills into it. An account with no structure assigned sees No structure assigned instead of the report.
• Admin (administrators only) — the general settings in the same order as the web "Admin" page: UI settings (First day of week: Sun, Mon or Tue), Auto-scheduling and Time and Attendance. Right on the phone you can change switches (they apply at once), numeric parameters (a sheet opens with the field, stepper arrows and Save / Cancel buttons, plus Clear for optional ones; the allowed range is shown under the field), times (an hours-and-minutes wheel in 30-minute steps) and multiple-choice parameters (a list with the current choice marked) — for example Round shift start to or Fact shift start/end rounding. The break ladder (Break) and Fact shift approval reasons are shown read-only; the company's interface language, roles, structure, deployment and the calendar are configured in the web version. Accounts with read-only access to the "Admin" section see the This account has read-only access in some sections card on top, and every control is disabled.

The store card on the phone. The Store Card button on the Store overview tab opens the same window as in the web app, and it is just as editable. The window's header carries the store's name, and right below it the switch between two tabs: Working hours and Shifts. At the very bottom of the window, under the tab's content, sit the Email field (an invalid address disables Save) and Store concept, a list of concepts with Not specified to clear it.

Working hours holds the Preparation and cleaning block — Working hours before opening (−6 to 6, step 0.5) and Working hours after closing (0–12), each entered in a sheet with stepper arrows where Clear returns the field to "—", i.e. to inheriting the general settings. Next comes the Open / close period block: one row per weekday, and the row shows the day's name, its guest hours (Closed on a closed day, Round the clock on a 24-hour one) and a red switch that closes and opens the day. Opening a day with that switch gives it 10:00–22:00, exactly as in the web version. Tapping a row opens that day's window: the Closed and Round the clock switches ("Technically 24 hours working (only manager and technical staff needed)") and the Since / Till hours (a 30-minute wheel; opening no earlier than 06:00, a closing time past midnight marked with ⁺¹). Save in that window carries the day back into the card, and Cancel closes it unchanged. The Shifts tab lists the manager shift types of the store's concept: the shift name in its own colour, Shift start and Shift duration, plus a Reset to default row on the ones that are overridden. Changes on this tab are saved immediately; everything else in the card is committed by Save at the bottom of the window (Cancel closes it without writing).

The shield button in the card's header opens Store login credentials: the organisation id, the Store login and the Password. The values are masked with dots and the eye icon reveals them; the Reset button next to the password issues a new one after a confirmation dialog, and the old password stops working at once. What is available depends on the role's permissions: without Open / close hours the Working hours tab is read-only, without Shift timing parameters so is the Shifts tab, and the credentials button is inactive without Can see store credentials. For read-only accounts every control is disabled and the Save button is not shown.

The team on the phone. The Team button opens the store's team list with a Search.. field (by name, "System employee ID" or "Additional ID"): every row shows the initials in the role's colour, the name, the role and, when there is one, a single training tag — On training or NSO; hidden team members stay in the list, dimmed, with a crossed-out-eye icon. The number next to the list's Team heading is the same one the button that opened it carries. When nothing matches the search — No employees found. Tapping a row opens that person's card with the same parameters as a row of the web table, each saved the moment it is changed: Role (needs the Can change team member roles permission; for employees from an integration the list is limited to the roles of their job title), Employee rating (0–10, step 0.5), Show (turning it off hides the person from schedules), the training status — No, On training or NSO (a "training only" role rules out No), the Available for shifts in other branches, Can work at night and All positions switches, three Positions by priority (1, 2, 3 — the concept's positions and position groups; one already chosen in another row is not offered again) and the Vacations/sick leaves row. That row opens the list of periods: each has a type (Vacation, Sick Leave or Other), a Period (a calendar with a range selection) and Delete with a confirmation, and Add absence period creates a new one. For a hidden team member every parameter except Show is disabled — the absence periods can still be read, but not changed. In the "By certifications" mode the same rules apply as in the web version: the role and position lists hold only what certifications open (the current value is marked "Not certified"), "On training" or "NSO" can be chosen only for employees without a certification, and there is no "All positions" switch. Adding and deleting team members, and the rest of the web employee card (contacts, salary, saved schedules), stay in the web version.

The store for the Store overview and Shift tabs is picked once — with the button showing the store icon and its name in the top bar (the list is titled Store). The list holds only the stores available to the account; the choice is shared by both tabs and remembered separately for each company server. With a single store available the button is inactive. Whatever the phone does not offer is done in the web version: such screens end with the hint Editing is available in the web version.

Notifications in the app. The Notifications bell sits in the top bar of every tab, opposite the avatar; the red dot on it is the number of unread notifications. It opens the Notifications screen with an All / Unread / Archive switch — the same three lists and the same notifications as the web app's bell. The screen opens on Unread. Tapping an unread row marks it read; the check mark in the top bar is Mark all as read (shown while there is something unread); the Archive read button at the foot of the inbox moves the read ones to the Archive. Pull the list down to refresh. An empty list says No notifications yet.

Signing in works the same as in the web cabinet: a one-time code sent to e-mail (the Send code button) or a password (the Sign in button) — e-mail, phone, login or employee ID plus the personal password. The Forgot password? link doesn't change the password right away: it e-mails a link that works for 30 minutes. Open it and press Send new password — the new password arrives at the same address, and the current one keeps working until then. The screen says Check your email even if the login doesn't exist or the account has no e-mail, so a stranger can't tell whether an account exists. An account gets at most three links an hour.

Google, Apple and Telegram sign-in. Below the sign-in form there are Sign in with Telegram and Sign in with Google buttons, and on iPhone the system "Sign in with Apple" button. A button appears only if your administrator enabled that method on your server, so the set can differ from one server to another. The app verifies the sign-in with Google, Apple or Telegram itself, and the server then matches the result against your employee card: the e-mail address (for Google and Apple) or the Telegram username has to be the one on the card — otherwise you get "No employee card matches this account" and an administrator has to add it. On iPhone these buttons only appear alongside "Sign in with Apple": if your administrator has not enabled Apple on your server the whole block is hidden and code and password sign-in remain. Apple's "Hide My Email" will not work: it hands over a throwaway address that is not on the card. If you later revoke ProSchedule's "Sign in with Apple" access in the iPhone settings (or delete the Apple Account itself), the server is notified and the link between that Apple Account and your employee card is removed — the card itself, your shifts and your hours are untouched, and signing in with Apple again simply asks for your consent afresh.

Company server. Every company runs its own ProSchedule server, and the app is connected to one of them at a time. A single card sits at the bottom of the sign-in screen at all times. Until your own company is connected it reads Add server and the app talks to the default ProSchedule server, so you can sign in straight away. Once connected, that same card shows the company's name and its server address, and the bin icon on it disconnects the server (the confirmation offers Delete), returning the screen to its original state. Connecting a different company simply replaces the current one; either way the sign-in data for the previous server is deleted with it. The current server's address is shown at the bottom of the Profile page. Changing server is only possible from the sign-in screen: sign out first.

The Add server screen opens on a single field — Company name. Enter the name your administrator gave you and the app looks up your company's server address for you in the shared directory. If your company isn't listed yet, the I have a server address link opens a Server address field (for example https://schedule.mycompany.com), and I have a company name switches back. Connect checks the address before saving it, so an address with no ProSchedule server behind it is reported straight away. There is no name to invent: it comes from the shared directory, or from the server itself if the company isn't listed there.

Signing in happens per server: each keeps its own session, valid for up to 30 days. Switching to another server, or removing one, erases the stored sign-in for the previous server — the device keeps no access to a company you no longer work with. Signing out or dismissal from the company also revokes access.

Interface languages — Russian, English, Hebrew (right-to-left) and Uzbek: the app follows the language set in the cabinet profile, and it can be changed on the Profile page.

Manager schedules live on the "Overview" in the Managers tab — a month card with the status and the tiles: "Hours" (against the ideal), "Over norm hours summ", "Under norm hours summ" and "Accuracy". The Add new schedule button creates the month that follows the most recent one. In the editor the month is picked with a selector (existing months), the store — with a search; the schedule team automatically receives the employees of the roles with the "Used in managers schedule" flag. There is no "Save" button — changes apply immediately, backed by "Undo"/"Redo".

The cell dropdown: "..." (clear), Day Off, Sick Leave and the shift types available to the store by concept and by the manager's role (see the shift types chapter). A shift and a day off displace each other; a yellow column background is the store's closed day. With the hard hours limits enabled the list shows "Available under the limit: … h" for that day and disables the shift types that do not fit the remainder (the remainder counts the manager's hours across all stores, including shifts in the employee schedule). The same line is in the custom time window ⚙ — there it turns red when the entered duration exceeds the remainder. An attempt to place the extra anyway is cancelled with the message "The shift exceeds the employee's daily hours limit" (weekly, monthly norm), and "Undo" will not restore a shift above the limit: "Cannot undo: the restored shifts would exceed the hours limit".

A closed day. When the store does not open on some day, mark it: click the day header and choose Mark the day as closed. The column takes the yellow background and a lock instead of the status icon, shifts can no longer be set on that day, and the shifts and days off already standing on it are removed. The point: a closed day is not counted as a hole in the schedule — it takes no part in the month's accuracy at all, which is averaged over the days the schedule actually asks something of. A closed day cannot spoil the month, and is not counted as a good day either. The managers' hours norm does not change either: it comes from the production calendar (see the weekends and holidays chapter), not from how many days the store is open. To bring the day back, choose Reopen the day — the shifts are not restored, they have to be set again (or press Undo right away). Days can only be marked in the "Draft" status and with the right to edit schedules.

A weekday the store never opens does not need marking: the schedule takes the opening hours from the store card (see the store card chapter). When a weekday has no working hours set there, no ordinary shifts are required on it — the day is not counted as a hole. Routines tied to that weekday (stock-takes, month-end closings) are still required and still placed automatically: shut doors do not cancel the work in the back. If such a routine is left unplaced it tells on accuracy exactly as it would on a trading day; a day nothing is asked of stays out of the calculation. Shifts can be set on such a day too.

In the grid such a day looks closed: a yellow column and a padlock instead of the status icon. The Mark the day as closed item is not offered for it, though — the day is closed by the store card and cannot be reopened from here; change the opening hours on the card instead. And if a routine for that day is left unplaced, the padlock gives way to the usual orange warning icon: shut doors are no reason to hide an outstanding stock-take.

Month auto-scheduling ⚡ completes the empty cells: first the preferences (if the "Use employee preferences in auto-scheduling" flag is on), then the additional routine shifts by their repeat calendar (the priority role goes first), then the day-part default shifts — honoring the day-part sequence (no morning shift after an evening/night one), the type's "Maximum number of shifts in a row", the limits on working-day series and day-off blocks, the hour norms and the shifts in other stores. Whoever is furthest below the yearly balance gets a shift first. The scheduler only adds: "Clean up schedule" before the run gives a blank slate. It respects the hard hours limits: a shift that does not fit the manager's remainder is not placed.

A schedule with no managers shows the No managers in the schedule card instead of the grid; in a draft it has an Update store team button. Managers can be added one by one with Add team member in the schedule header.

The route from an empty month to an approved schedule:

1. Create the month: "Overview" → the Managers tab → Add new schedule; open it in the editor.
2. Update the store team ↻ — the lineup, roles and norms are pulled from the current cards.
3. Collect the preferences: the Schedule preferences window; turn the eye 👁 on if the scheduler should start from them.
4. Run auto-scheduling ⚡ — the routines and default shifts close the month by the type rules.
5. Walk the day badges: first the red ▲ (the working hours are not covered), then the orange ! — hovering tells which shift is missing or extra.
6. Check the hours against the norms at the end of the rows: red — overwork; clicking the number shows the breakdown by shift types. A single shift's time is edited with the gear ⚙ on its cell.
7. Review the "Team rating" by day and leave "Comments" for the colleagues where needed.
8. Submit and approve: ✈ (needs accuracy ≥ the managers' minimum and zero critical conflicts), then ✓ Approve.
9. Print 🖨 "Print month schedule" — the PDF for the shift board.

The header holds Store (search by name), the date with a back-to-today button (the calendar starts on the first day of the week from "UI settings") and a search over the list: by name, "System employee ID" or "Additional ID". The chosen store is remembered.

KPI tiles: Revenue — the day's fact / forecast and the deviation from the forecast up to the current hour; SPMH and TPLH — fact / plan; Hours — the day's fact / planned hours (red once fact is already above plan); Compliance — the share of marks that matched the schedule: green above 90 %, orange above 70 %, red below. Under the tiles — Data on with the time of calculation.

Three buttons sit above the list. Add shift opens a person who is not in that day's schedule: search over the store team, and with the From current store checkbox off — over other stores; the button is available only with "Shifts can be clocked manually" enabled — the same checkbox turns the clock-in and clock-out controls in the rows on and off. ⚡ sets clock-in and clock-out by the schedule for everyone at once — after the question "Are you sure to set clock in/out time by scheduled shifts for all employees?". With "Shifts can be clocked manually" off the dialog says so separately: only the shifts already clocked in through biometry are set by the schedule, and no shift is created for anyone who did not clock in. Print exports a PDF of the list exactly as shown: same search, sorting and groups.

The list is split into Managers, Employees and No schedule. Columns: Name, Clock in/out, Schedule, Shift break (only with "Placed lunch breaks" enabled), Position, Hours. Clicking the "Name" or "Schedule" header sorts; the choice is remembered.

Edits are available when the role may edit actual shifts, the day is not beyond "Editing of shifts … closes on date" and the time sheet for that day is not yet approved (see the time sheet chapter). Otherwise the whole page is read-only.

The badge on the clock-out button sums up all the person's fact shifts of the day: a green check — all approved (Approved); an orange question mark — there is an edit with the status Awaiting approval; red — there is a Not approved (rejected) edit or a shift that is not counted: "Shift is before the hire date and is not counted", "Shift falls within an absence period (vacation/sick leave)" or "Shift started after the limit was reached — recorded with zero hours". A red badge with a check inside — the edit was rejected and the previously approved time applies: that is what the buttons show.

Start and finish a shift. While there is no clock-in mark, clicking "…" asks: "The shift opens at its scheduled start time. You can edit the clock-in afterwards." — with the Start shift button. While there is no clock-out mark — Finish shift: "Clock-in and clock-out of every shift this person has today will be set to the schedule. If the schedule is approved, the records are approved right away." Both buttons set the time by the schedule, not "now"; a person without a schedule has neither — their time is entered in the edit window.

Schedule — the "from – to" periods from the employee schedule or the manager schedule; a red prohibition sign — no schedule for the day. Position — a coloured dot and the position name; for managers — the shift type.

Clicking a time opens the "‹Name› — clock in/out" window. It has a row per fact shift of the day: the Clock In, Shift break (read-only — computed from the break ladder) and Clock Out fields. A time beyond the allowance from the settings will not save: "Clock out time is more than max hours before shift start" / "Clock out time is more than max hours after shift end" — see "Max allowed time before shift start" and "…after shift end". Two buttons sit at the right of a row: ↻ Reset to schedueled (clock-in and clock-out are set to the plan) and 🗑 Delete — the shift goes to the archive: it leaves the totals, but its history stays visible, dimmed. The Add shift button opens a second shift of the same day once the previous one is closed. Save writes only the changed times; such an edit enters the history with the status Awaiting approval.

History of changes — the table under the fields: Initator, Clock in/out, Comments, Time of change, Status. The top row is the one in force; below it — the whole history in a dimmed colour. Biometry and terminal marks are signed "Integration"; automatic trims (before opening, after the store closes, by the limits) are explained right in the comment.

Approval. The top record with the status "Awaiting approval" has two buttons: ✓ Approve — opens a window with the Select a reason field (ready-made wordings from the "Fact shift approval reasons" setting) and a comment — and ✕ reject with a mandatory comment. Who may approve employee shifts and who manager shifts is set by the role permissions (see "Access parameters"); for a person without a schedule either permission is enough. A rejected edit is not deleted: the last approved time becomes the one in force, and the day's badge turns red until a manager sorts it out. Statuses in the column: Approved, Awaiting approval, Not approved, Archived.

With the "Hard daily hours limit / Hard weekly hours limit / Hard monthly hours limit (norm)" checkboxes on (see the rule in the settings) two marks appear on the page.

• A zero-hour shift — the limit was already used up before the clock-in: clock-in and clock-out are recorded with one time, the day's badge is red, the hint reads "Shift started after the limit was reached — recorded with zero hours" with the window name ("Daily hours limit reached", "Weekly hours limit reached" or "Monthly hours norm reached"). In the history that record carries a chip with the same name, and the comment holds the real clock-out time. Such a shift counts as zero in the totals.
• A cut shift — the clock-out was moved to the moment the limit ran out. The shift's status does not change (it may be approved or awaiting approval), but the scissors ✂ stand next to the hours with the hint "Shift cut at the hard hours limit" and the same window name; the chip is in the history too. The "tail" after the cut cannot be brought back by approval: approval re-checks the limit and cuts the extra hours again.

Manual time edits, "Reset to schedueled" and ⚡ go through the limit as well: time beyond the remainder is cut on save with an explanation in the comment. Hours can be freed only by archiving another shift of the same window. When several reasons apply to a day at once, the hint names the main one: before the hire date → absence period → hard limit.

The Print button exports the PDF "‹Store› Shifts_‹date›": a header with the store and date, the KPI tiles with deviations and the same Managers, Employees, No schedule groups in the current sorting and with the current search. Statuses are printed as glyphs: ✓ — Approved, ? — Awaiting approval, ✕ — Not approved, ○ — a clock-in without a clock-out; deviations from the schedule — signed. Shifts before the hire date, within an absence period and zeroed by the limit are marked with footnotes under the table, the ones cut by the limit — with an asterisk next to the hours. Colours in the PDF are hints only: black-and-white printing loses nothing.

Pick a Store and a Period in the header. Next to them — a search over employees: by name, "System employee ID" or "Additional ID". On the right: Filters (roles, Shifts — Store only or Whole team, and Show dismissed employees), the "list ↔ calendar" toggle, Print, Approve ✓ and Cancel approval ✕.

The approval level comes from the user's role — see "Role rate and time sheet approval level". Without a level both buttons are inactive. The approval covers the last completed day of the period (never later than yesterday).

Shifts hit by the hard hours limit. A shift recorded with zero hours (the limit was already used up before the clock-in) is shown in the calendar with a red cross and "- -" instead of hours, and in the employee window — with a single clock-in time; it enters the totals as zero. A shift cut by the limit keeps its status but gets the scissors ✂ (in the calendar — an orange dot in the cell corner); the hint names the window: "Shift cut at the hard hours limit (Weekly hours limit reached)". In the employee list a red counter of such shifts stands next to the name — "Shifts hit by the hours limit". In the printed form the days with zero-hour shifts are highlighted red. The same icons stand on the "Shift" page: on the card, in the "Clock in/out" window and in the history of changes.

All three buttons — Print, Approve ✓ and Cancel approval ✕ — open the same Select stores window: search by name, checkboxes, Select all and Reset. Print exports one file covering every ticked store; approving signs each of them off for the selected period, and cancelling lifts that signature.

The current store is ticked in advance — provided the chosen action is available for it at all. The rest are greyed out with the reason. When approving that is Already approved — your level has already signed the time sheet off through that day; when cancelling it is Not approved — there is nothing to lift. Common to both actions is Approved at a higher level: the signature above must be cancelled first.

Stores are handled one by one. If some of them fail, the window stays open and shows Could not be approved (or Could not cancel the approval) with their names: the others are already done and need no second attempt.

An approval closes fact-shift editing up to and including the stated day — on the "Day overview" page and in the corrections report too; cancelling reopens it. Cancelling lifts the topmost signature that is not above your own level, so calling it again lifts the next one down.

Header. Unit — your branch of the structure; Back in the caption line goes one level up. If no unit is assigned to the account, the page shows "No structure assigned".

Month. It is switched with the Previous period and Next period arrows; Current month brings you back to the current one. Future months are unavailable. The current month is calculated live, a past one — from the saved snapshot (see "PPR month"). If some of the stores have no snapshot, a yellow No snapshot banner appears at the top: for those stores the current data is shown. The month is kept in the page address, so the link can be shared.

Charts.

• Managers structure — fact and ideal for each manager role, with the fulfilment percentage at the end of the bar (in the tooltip it is labelled "Fact / Ideal").
• Employees structure — two rings: the outer one is the employee team by role, the inner one is the share of "Trainee" in the whole team. In the legend, each role and "Trainee" show the number of people and the share of the team under "Fact", and the configured minimum share under "Ideal" (0 % — no minimum). There is no "Ideal" column if no tier fits any store.

Columns of the "Structure" table. A row is a unit or a store.

• Average monthly sales — from the sales forecast;
• a column per manager role — "fact / ideal" and the fulfilment chip;
• a column per employee role — "fact / ideal" in people, where the ideal is a minimum, and a chip: green — the minimum is met (with a 0 % norm — a ✓ tick), yellow — 50 to 99 % of the minimum, red — below 50 %, grey "—" — there is no norm;
• "Trainee" — "fact / ideal" in people and the share of the team, with a chip by the same rule: above the minimum is green too;
• for a past month, two more columns: the month status and PPR approval level.

If the store itself is selected in the header, the table is replaced by the Open restaurant PPR button. On a phone the table turns into cards: the name, "Average monthly sales" and the staffing of "Employees" and "Managers".

If the selected structure has no stores, the table is replaced by the No stores in this structure card with an Open settings button: stores and the ideal structure are set up in the "Admin" section.

• Who is counted. Only employees of roles used in the employee schedule or in the managers schedule; roles outside both schedules do not get into PPR.
• Who is a manager. An employee of a role with "Used in managers schedule". The rest belong to the employee team.
• Where the ideal comes from. From the ideal structure tier the store falls into.
• Breakdown. Trainees go into a separate "Trainee" line, everyone else — by their role; every person is counted once. Who counts as a trainee — see the "PPR settings" section.
• The ideal per role is a minimum: the role's share × the headcount of the whole employee team (trainees included), rounded up; the same for "Trainee". For example, 10 % of 33 people is at least 4.
• The fact per manager role — without trainees.
• Store groups. Headcounts are added up. The ideal in people is added up only over stores a tier fits, while the fact — over the whole team. The "Ideal" share in the chart is those stores' configured shares weighted by the size of their teams: stores without a norm do not dilute it.
• Staffing on a phone. "Managers" — the share of manager roles where the fact is not below the norm. "Employees" — the team headcount against the ideal headcount: the week's recommended hours from the "Deployment" tab divided by 40. For a group — the average over its stores.

Snapshot.

• While the month is under way, PPR is calculated live.
• After the month ends, a snapshot is saved: the team makeup, the tier norms, the employees' roles and "Trainee" status, and the valid certifications. From then on the month is shown from the snapshot, even if the team has changed.
• The snapshot is taken automatically on the 1st of the next month. If it was taken later, the chosen month is marked "Snapshot taken late".
• The first approval also takes a snapshot — with the data at the moment of pressing; the "As of" date is recorded on it as a mark. If the current month is approved before it ends, the snapshot is taken immediately, and the automatic snapshot on the 1st is no longer made for that month (cancelling the approval does not delete the snapshot).
• If a past month has no snapshot ("No snapshot"), a role with an approval level can take it with the Take a snapshot button; such a month is marked "Snapshot taken manually".
• HR statuses, comments and actions are not part of the snapshot — they are closed by the approval or by the editing window.

Month history. When a single store is selected, the month is picked from the Month history list: the saved months and the current one, marked "Current month", "Snapshot", "No snapshot", "Approved". For a group the months are browsed with the arrows. The month chip has an Approved by tooltip: the levels, names, "As of" dates and the snapshot time.

The Approve the PPR ✓ and Cancel the PPR approval ✕ buttons are available to roles that have a "PPR approval level". Both open the Select stores window, as in the time sheet: search, checkboxes, Select all and Reset; unavailable stores show the reason. When approving, you pick the As of date (within the month, no later than today) and can leave a Comment. Stores are handled one by one; the window lists the ones that failed.

Level rules — as in the time sheet.

• The approval is placed at your role's level.
• If a higher level has already approved, you will see "Approved at a higher level".
• Approving again at your own level only moves the "As of" date forward.
• Cancelling lifts the topmost signature that is not above your level; cancelling again lifts the next signature down.

Notifications. "Month PPR approved" and "Month PPR approval cancelled" go to the store's PPR editors and to every level above. Whoever pressed the button gets no notification.

HR statuses, comments, actions and certifications can be changed only if all the conditions hold:

• the role has Can edit the PPR;
• the month is not approved at any level;
• the window set in the "PPR settings" section has not closed: the current month — until the set day (by default until the end of the month), the previous one — until the set day of the next month (by default it closes immediately), earlier ones — never.

If editing is closed, the store page shows a banner with the reason (for example, "The month is approved, editing is closed"), and the editing buttons are hidden. The data stays visible.

The page opens from the "Structure" table or with the Open restaurant PPR button. In the header: Store (the month is kept when you switch stores), Back to the overview, the month and the state chip, Take a snapshot, ✓ and ✕ — for this store only — and Download. The month can also be switched to the next one, marked "Upcoming": its HR statuses, comments and action plan are filled in ahead of time; an upcoming month can be approved once it starts. Tabs: Overview, Certifications and Action plan.

The page's data is refreshed after every change, when you switch tabs and when you return to the window; changes made in another browser tab (in the certification catalog, for example) are picked up by themselves. If the data cannot be refreshed, Couldn’t refresh the data appears above the tabs with a Retry button — until then the screen shows the last data that loaded.

The same two charts as in the overview, and the Employees table, split into Managers team and Employees team. The columns:

• Name — with the marks "On training", "NSO", "All positions" (only for employees and only in the "Simple" mode), "Instructor", "No employee card";
• Role and With the company since;
• HR statuses, Comment and Planned actions;
• Certifications — in both modes.

The table always shows the store's current team; the statuses, the comment and the actions shown are the ones valid in the chosen month. A click on the row or on the arrow at its end opens the employee panel.

Columns. The Columns icon in the right corner of the table header opens the list of columns: the checkbox hides a column, the arrows move it. "Name" always comes first. The choice is saved for you only, in this browser; Reset brings back the default view. Once the charts scroll away, the table header stops under the tabs and the rows scroll beneath it.

HR statuses. A click on the cell opens the list of suitable statuses. A ticked status has a Status note field, and if the status requires it — a Key date too. The ↩ icon means that the status was carried over from the previous month. If you remove a carried-over status, it disappears from the current month but stays in the past months.

Comment. Each month has its own; it does not carry over to the next month. It saves automatically; the Comments from the previous months button shows the earlier ones.

The employee panel brings everything together: statuses, the comment, "Planned actions" and certifications with their granting history.

Matrix. Rows are employees (the "Employees" / "Managers" switch picks the group), columns are the active certifications of the catalog: position certifications first, then role certifications. The tab is there in both modes. The cell colour shows the state: "Valid", "Expiring", "Expired"; the cell holds the expiry date, ✓ — a never-expiring certification. The number of people, "Today: <date>" and the state colours are in the matrix's top-left cell; while you scroll, the matrix header stays under the tabs.

• A click on an empty cell opens Grant: Certification date, Valid until (filled in from the certification's validity) and Confirmed by.
• A click on a granted certification — Renew or Revoke. For an expired certification the window offers a new term right away — starting today; a valid one opens with its own dates.
• Tick several people and press "Grant to the selected (N)" to grant to all of them at once.
• Above the matrix is a single row: "Employees" / "Managers" with the number of people, search, role, "Expiring in the coming days" and "Grant to the selected". If the button is inactive, its tooltip says why (on a phone — a line under the button).

An empty cell without "+" means that this certification cannot be granted to the employee's role. An employee who already holds the certification keeps it and can renew it. If someone holds a certification of the other group (for example, a manager holding a certification for employee positions), its column appears on their side too: that certification can be renewed or revoked there, but not granted to this group. Archived certifications are not in the matrix, but granted ones stay with the employees. The bell reminds the PPR editors of the employee's main store about a certification's expiry.

Empty catalog. While the catalog has no certifications at all, the tab shows a grey card, No certifications yet, instead of the matrix and the row above it. An administrator fills the catalog right from it: Add certification opens the same dialog as in the PPR settings (access "To positions" is picked first; it can be switched to "To roles"), and Create from the positions, after a confirmation, creates one never-expiring certification for every position that requires one and grants nothing to anybody. Once the dialog is closed, the matrix appears on the tab. Everyone else is told that certifications are set up by an administrator. In a closed month there are no buttons.

The card also stands in for the matrix in the other empty cases: Every certification is archived, nobody in the selected group (a button in the card switches to the other group), or No certifications for this group. Only the "Employees" / "Managers" switch stays above it.

An action is added in the employee panel: Action, Details, Due date and Assignee. Action statuses: "Planned", "In progress", "Done", "Cancelled".

• An action that is not closed moves into the following months with a "Carried over from …" chip until it is closed.
• An overdue action is marked with a red date and an "Overdue" chip.
• When an employee transfers from another store, their open actions move with them, with a "Created in …" chip.

The Action plan tab — all the store's actions for the month in one table. Filters: Status, Employee, Overdue only, Including those who left. Tick several rows and close them at once with the Mark as done (N) button.

Due-date reminders arrive in the bell as many days in advance as set in "Remind in advance, days". They go to the store's PPR editors, the action's author and its assignee.

While the month has no actions at all, the table is replaced by the No actions card with a Go to the team button: actions are added on the "Overview" tab. Only Including those who left stays above the card — it can bring back the actions of people who left.

Download saves the file PPR_<store>_<month>.xlsx. It has a single sheet, with the blocks going from top to bottom:

1. "Managers structure";
2. "Employees structure" — by role and "Trainee"; in the "Total" row the "+ / -" column shows only the shortage;
3. "Certifications" — the legend, if there is anything to show;
4. "Managers team" and "Employees team" — one table per group: role, job title, HR statuses and comments, to the right a column for each certification that can be granted to someone in the group or that someone in it already holds, and at the end of the row the "Action plan": "Action", "Status", "Due date" and "Carried over from". Everything about an employee is on one row.

Several actions go on separate numbered lines of the cell, in the same order in all four columns. An overdue due date is highlighted in red and marked "Overdue".

A certification cell holds the month and year of expiry ("MM.YY") on the state colour, ✓ — never expires, a grey cell — the certification cannot be granted to the employee's role, an empty one — no certificate. The certification names in the header are rotated and wrap at spaces.

Schedule (employee schedule)

The weekly shift plan of line staff by position. Statuses: Draft → Submited → Approved.

Manager schedule

The monthly plan of manager shifts, built from shift types (chapter 07).

Position

A workplace in the schedule ("Cashier", "Kitchen"), configured in the "Deployment".

Recommendation

The system-calculated number of people per position in each half-hour — from the revenue forecast and the position's ladder.

Accuracy

The percentage match of the staffed schedule to the recommendation. The approval threshold is set in settings.

Fact shift

Actually worked time: clock-in and clock-out marks with an edit history and an approval status.

Time sheet

The summary of fact hours for a period with multi-level approval and editing lockdown.

Schedule preferences

Employees' requests for desired working time; auto-scheduling honors them where possible.

Store concept

The venue format; the key by which positions, shift types and the ideal structure are selected.

Order channel

A revenue source (dine-in, delivery, drive-thru). The day's revenue is split by channel, and positions scale by channel.

Job title

The employee's position name in the HR system; mapped to ProSchedule roles in the "Job titles" dialog.

Role

A set of permissions and schedule participation parameters; assigned to every employee (chapter 04).

On training / NSO

Trainee statuses: a regular trainee and a new store opening trainee. Mutually exclusive; set in "Team parameters".

SPMH / TPLH

Sales (transactions) per man-hour — the productivity metrics of the dashboards.

COL

Cost of Labor: hours × rate × ratios, compared against revenue.

PPR

The "People Planning Review" report: the stores' team makeup against the ideal structure, HR statuses, the action plan and employee certifications. The month is fixed by a snapshot and approved at three levels.

HR status

A mark on an employee in PPR ("Newcomer", "At risk of leaving"…) from the "HR statuses" catalog; it can carry over to the next months and have a key date.

Month snapshot

The saved state of a store's PPR for a past month: the team makeup, the norms and the employee statuses. Taken automatically, on approval or manually.

Certification

A confirmed employee skill: admits to positions or opens roles. Never-expiring or with a validity period.

Instructor

An employee of a role with "Can train employees" in the "By certifications" mode while "On an untrained position only with an instructor" is turned on: their shift covers training shifts on the same position.

Universal

The card's "All positions" switch in the "Simple" mode: the employee fits any position. Employees only, not managers.

Hard hours limit

A ceiling of the employee's paid hours per day, week or month (three checkboxes in "Time and Attendance"); hours above it are neither recorded nor planned.

Fallback calendar

A month saved on the "Weekends and holidays" tab while an external calendar is connected; it applies when the external source is unavailable.