Key Features
- Teacher approvals and return tracking
- Escort-required supervision workflow
- Counselor scheduling and destination kiosks
About SMM
Student Mobility Manager
A district-managed, campus-configurable system for student location-change requests, approvals, check-ins, scheduling context, and campus-wide movement visibility.
Novato Unified School District
System Overview
Base case, options, and benefits.
Supported devices
- Chromebooks for students and kiosks
- MacOS devices for teachers and administrators
- iPads for teacher and admin touch workflows
- Smart phones, for Campus Supervisors
Minimal Base Case
The system is designed so that schools can begin with the simplest useful workflow.
- From any location, a student can request a location change.
- Staff can also use the same flow simply to record a location change that was verbally approved.
- This minimalist workflow can operate by itself, without any of the additional optional features enabled.
Optional Functionality Layers
After the minimalist base case, schools can enable additional capabilities in phases rather than all at once.
Request control and accountability
- Require approval through the system by a teacher or other authorized staff member.
- Allow simple record-only usage when a location change has already been verbally approved.
- Allow staff to record approval notes.
- Require notes for certain categories such as off-campus travel.
- Allow persons approving requests to open the student profile and see recent same-day request activity.
- Allow staff and administrators to review longer-term request behavior patterns.
Check-in, check-out, and timing options
- Require check-out from the starting location.
- Require check-in at the destination.
- Require return check-in at the starting kiosk for selected destination types.
- Set default or ad hoc trip and return times.
- Trigger optional automated alerts when a student is gone too long or takes too long between locations.
- Route alerts to teachers, front office staff, and/or campus supervisors depending on campus preferences.
- Clear older unresolved or active passes while preserving records and labeling cleanup accurately.
Student identity and hardware options
- Use student ID cards and optional barcode scanners to speed entry.
- Support manual student ID entry when scanners are not available.
- Keep student self-service limited to student ID / barcode, not student-name search.
- Allow staff-assisted request creation by student name when appropriate.
Safety and supervision options
- Maintain escort-required flags for specific students.
- Trigger optional alerts when escort-required students request movement.
- Route those alerts either directly to campus supervisors or to the front office for walkie-talkie coordination.
- Set campus-wide active-pass limits in addition to per-destination capacity limits.
- Block or constrain certain student movements depending on campus policy.
Specialized staff workflows
- Route certain requests to office/admin workflows.
- Support counselor scheduling workflows and counselor availability windows.
- Provide campus-wide request boards, teacher queues, and student profiles for operational follow-up.
Schedule-aware intelligence
- Store bell schedules inside SMM.
- Store teacher/class location assignments by class period.
- Store student schedules to determine expected student locations by period.
- Apply weekday default bell schedules plus date-specific override schedules.
- Continue to function with fail-safe/manual fallback when schedule data is incomplete.
Import and integration options
- Import student names and student IDs from Aeries.
- Import student schedules and/or class assignments from Aeries.
- Potentially import other schedule-related data later through richer integrations.
- Keep SMM as the owner of bell schedules and local operational rules even when Aeries supplies roster data.
Frequently Asked Questions
What is the most minimal way this system can be used?
At its simplest, a student can request a location change, or staff can simply record that a location change already occurred based on verbal approval. That base case can operate without the optional scheduling, alerting, or kiosk features.
Does this require scanners?
No. Barcode scanners are optional. They are useful as a speed and accuracy upgrade, but the system can also work with manual student ID entry.
Does this require Aeries integration before it can be used?
No. Aeries import is beneficial, especially for students, staff, sections, and student schedules, but the system can still function with local/manual setup. SMM is intended to own bell schedules and local operational rules.
Can the system work even if schedule data is incomplete?
Yes. Core movement-request workflows can still function. When schedule data is missing, staff can fall back to manual class or workflow selection instead of the system failing completely.
Can schools start simple and add features later?
Yes. That is one of the main design goals. The system can begin with a minimal request/record workflow and then add approval requirements, check-ins, timing alerts, escort logic, scheduling intelligence, and integrations over time.
Can teachers or staff make requests on behalf of students?
Yes. That is useful when a student forgets an ID or needs assistance. Student self-service stays more restricted, but supervised staff workflows can be broader.
Can the system support counselor, office, and campus-supervisor workflows too?
Yes. The system is designed to support more than classroom passes. It can route requests differently depending on destination and campus policy, and it includes campus-level visibility for support staff.
Is this ready for a full pilot today?
It is in a strong state for stakeholder demonstration and remote role-based feedback testing. A real small-scale trial or full campus pilot should still use district-approved authentication, verified backup/restore procedures, import/reconciliation testing, operating procedures, and final policy/notification decisions.