Input data
Proposal · the fields below are a draft, not a finished format
The service would need three things from a store: the team, the rules, and the traffic. This page lists the fields we currently expect to need.
Team
| Field | Example (illustrative) | Notes |
|---|---|---|
| Name | Anna | |
| Roles | Cashier, key holder | What the person is allowed to do |
| Contracted hours | 30 per week | Target, with an allowed range |
| Availability | Not Sundays; not after 18:00 | Recurring and one-off |
| Preferences | Prefers mornings | Soft: honoured when possible |
| Leave and absences | 10–14 March | Hard: never scheduled |
Rules
| Rule | Example (illustrative) |
|---|---|
| Opening hours | Mon–Sat 08:00–22:00 |
| Minimum staff per role | At least one key holder open |
| Shift length | 4 to 9 hours |
| Minimum rest between shifts | 11 hours |
| Maximum hours per week | 40 |
| Breaks | 30 minutes after 6 hours |
Labour rules differ by country and contract. We do not plan to ship a legal rule set in the first version; the store states its own rules. See Open questions.
Traffic
Traffic tells the agent how many people are needed at each hour. Possible sources, from most to least precise:
- Footfall counter data by hour.
- Number of till receipts by hour, exported from the point-of-sale system.
- The manager’s estimate (“quiet mornings, busy 12–14 and 17–19, Saturdays twice as busy”).
The agent turns traffic into a required headcount per hour. How exactly (a fixed ratio, the manager’s own targets, or learning from past schedules) is still open.
Format
For a first version, spreadsheets are the likely entry point, since that is where most stores keep this data today. Integrations with HR or point-of-sale systems come later, if at all.