Your reply closed every open design question. Three remaining design calls (per-operator scheduling flexibility, supervisor login mechanism, correction-task workflow) we resolved on your behalf using industry-standard defaults, explained below. The new features you suggested (supervisor role, floater dashboard, before-and-after photos, ticket SLA labels, multi-role photo approval) are scoped and ready to build.
Nine were your direct answers. The last two we resolved on your behalf with industry-standard defaults so you don't have to think about back-office plumbing. All eleven are explained below. Flip any of them by reply if you disagree.
Your answer: Admin picks the employee, system suggests from the Floater pool, then generates the 12-month schedule.
Your answer: Same 68 items as employees, so admin can do a true item-by-item comparison.
Your answer: Operators only see approved photos. (Updated based on your other feedback below: supervisors and admins can both approve, no admin-only bottleneck.)
Your answer: English only for operators and admins. Bilingual toggle stays on the employee portal where it matters.
Your answer: Soft block when an employee is assigned to a 5th store, plus auto-notify the admin every time the override happens.
Your answer: Same across all stores. Biweekly tasks use Mon to Sat (Thu/Fri/Sat fill the floater's calendar), monthly and long-term tasks can pack onto biweekly cadence days.
Your answer: Admin gatekeeps. Employee reports route to SaniFilPro admin first, who triages and forwards to the operator if action is needed.
Your answer: Admin uploads and manages everything. Operators get read-only download of receipts and full history.
Your answer: Automatic retry is fine. No manual "retry now" button needed.
Confirmed previously: Live capture only, no gallery picker, no fallback. Zone name + timestamp burned into every photo (Timestamp Camera Basic behavior).
Our call: Email + password (no 2FA). Stronger than a PIN, lighter than the admin login. Matches industry norm for back-office roles, and field managers logging in 5 times a day across different store wifi networks shouldn't be fighting 2FA prompts. Easy to add 2FA later if you ever want to bump it up.
Our call: When a supervisor flags an item Unsatisfactory + attaches a photo, the next-shift cleaner sees the flag photo at the top of their checklist, re-cleans that zone, then captures a new "after" photo as proof of the fix. Closes the loop with a visual before-vs-after on every flagged issue. ~30 seconds extra per correction, no supervisor re-verification needed.
Your feedback on supervisors and floaters means the role hierarchy needs a refresh. Here's the new layout: four staff roles on the SaniFilPro side, one customer role on yours.
These two are easy to mix up because they both sound like management roles. They are on opposite sides of the relationship:
Your original game plan grouped "Cleaners and supervisors" under one Employee role. Your new feedback (rightly) bumps Supervisor up to its own distinct tier with separate access. Here's the full picture:
Operator sits outside the staff hierarchy entirely. They have a completely separate permission tree. A SaniFilPro admin can never accidentally see an operator's personal data, and an operator can never see anything about another operator's store. This is enforced at the database layer, not just the UI.
Five additions we're committing to based on the suggestions in your reply. Each one is scoped well enough to build now.
Replace the current Low / Medium / High / Emergency labels with four priorities aligned to your operations: Routine, Important, Urgent, Before Opening. "Before Opening" is special because it implies a time-sensitive resolution before the next store opening, which gives operators clear expectations on response time.
v1: just labels. v2 (after launch): automated SLA timers that page on-call staff when "Before Opening" tickets are within 2 hours of store opening time.
New supervisor login + dashboard. Supervisors visit stores, fill a verification checklist (same 68 items as employees), and approve photos. If a supervisor marks an item Unsatisfactory and attaches a verification photo, the system automatically creates a correction task for the assigned cleaner on their next check-in.
Example workflow you described:
This closes the quality-control loop. Issues caught by supervisors automatically become required work for cleaners, not buried in emails or text messages.
Both supervisors AND admins can approve uploaded photos. Eliminates the bottleneck of having one admin be the gate. Operators see approved photos within minutes instead of hours.
An audit trail is kept of who approved what, so if you ever need to know "who signed off on the May 12 Daytona photos", it's one click.
Floaters get a separate dashboard tuned to project work. Key differences from a regular cleaner:
A floater seeing "Wipe down all tables and chairs" when they came in to scrub the freezer floor would just confuse them. Scoping the checklist to what they're actually doing makes the shift faster.
New photo-type distinction. Cleaners can capture "before" photos at the start of their shift to document the state of each zone when they arrived (protecting SaniFilPro if the operator's own staff didn't do their pre-close prep). "After" photos capture finished work, same as today.
In the operator's photo history view, before/after pairs appear side by side under each zone, so you can see "this is what we walked into, this is what we left." Clean visual proof of value delivered.
Default: "before" capture is optional but surfaced as a quick tile per zone at the start of a shift. We can make it required later if you want it enforced.
You said "same across all stores: Mon to Sat with monthly + quarterly packed in." We're going to build slightly more flexibility into that, here's why.
Each store gets a list of allowed biweekly days, stored in the database. Default value: Monday through Saturday (matching your spec exactly). The scheduling algorithm respects each store's allowed-days list when generating the 12-month calendar.
Right now you're the only operator. Your preference is the default, so nothing changes for you. When you bring on operator #2:
Without the per-store flexibility, you'd be telling them "tough, our system can't do that" — which contradicts the whole operator-first pitch of the platform.
Building it flexibly now: one extra database column, one multi-select widget in the admin Add Store form, two extra lines in the scheduling algorithm. Maybe 30 minutes of work.
Retrofitting it after launch: database migration, recompute every active project schedule, UI rework, risk of breaking existing operators' confirmed calendars. Days of work, real downtime risk.
Cheap insurance against future you wishing past you had built it flexibly.
Phases run in parallel where the database schema permits. We're kicking off Phase 1 this week.
The day estimates above are heads-down engineering time, not calendar time. Phases run concurrently when the schema permits (the scheduling algorithm and supervisor portal can be built in the same week, for example). Realistic calendar estimate: v2 build complete and ready for your UAT in 2 to 3 weeks.
Phase 1 starts on the schema additions. You don't need to do anything unless you want to push back on a decision above. The mockups linked in the nav stay live for reference. We will send you a preview link as soon as the supervisor portal and floater dashboard are clickable.