ClassShift is being built so commitments, changes and approved work have a visible state—and so real exceptions have a defined human path.
Preview and pilot design—not operating proof. Providers, policies, commercial terms and worker-facing rules must be finalized and disclosed before a live assignment relies on them.
A polished interface only matters when the underlying rules are understandable, consistent and grounded in the approved pilot model.
A real assignment should disclose the employing/contracting structure and relevant work terms before a student is asked to rely on them. The final pilot employment/payroll architecture is not claimed as live on this pilot-stage website.
A shift should show the workplace, supervisor, role, dates, hours and relevant requirements before a student accepts it.
Matching is designed around the complete schedule pattern, class conflicts, commute range, role requirements and repeat availability.
Students, employers and operators should work from the same underlying shift state, with role-specific next actions instead of conflicting inbox threads.
Submitted time, approval, attendance decisions and relevant next steps are designed to be visible rather than buried in support email.
Automation can assist reminders and routine status. Safety concerns, disputed time, emergencies and judgment calls require a defined human escalation path before live operations.
The student should see the next action. The employer should see coverage and approvals. The operating team should see the exceptions requiring attention.
ClassShift has not yet published an approved final employer-of-record or payroll structure, insurance arrangement, screening provider, payroll cadence, pricing model or support-response SLA for a live DFW pilot.
Exact cancellation, attendance, dispute, settlement and appeal rules also remain subject to the approved operating/legal model. This website does not invent them.
Ask a trust or pilot question