# Game-Night Workforce Scheduling

**BrightDesk | Prepared for Zachary Webster, Orlando Magic | September 2026**


## 1. Executive Summary

At the event, the Magic described how last-minute staffing changes place a significant strain on the organization, leaving managers to coordinate urgent changes while running game-night operations. Our proposed tool will address this through three guiding principles: **Prevent** avoidable gaps by identifying staffing risks early, **Prepare** managers with a clear readiness view and qualified backups, and **Pivot** in real time with actionable replacement options when plans change.

Our team will begin by observing a live event and documenting the process with Operations, HR, and IT. We will then design and build a working prototype, targeted within 90 days of an agreed start date, followed by a controlled pilot and iterative releases. Scope, access, and team availability will determine the final schedule.

The tool will support the team's preferred way of working, in an app or a browser. ABI compatibility and support for the existing HR/payroll process are required. During discovery, we will determine whether scheduling stays in ABI or moves into the new tool.

### Why BrightDesk

- **Milestone-based delivery.** Our delivery milestones will provide clear acceptance points and opportunities to continue or exit.
- **User-centered design.** User experience design is a key differentiator for BrightDesk. We will design the tool so managers can understand what changed, assess their options, and decide what to do next.
- **AI-driven development.** We will use AI-driven development to support prototyping and iteration. Any deployed AI and use of staff data must meet the Magic's IT and governance requirements.
- **Proven process reliability.** Managers will initially review recommendations. We will introduce automation only after observed use demonstrates that the underlying process is reliable.
- **Enterprise experience.** Our team brings experience across a variety of organizations, including work supporting an organization with more than 4,000 employees nationwide.

## 2. Business Context & Opportunity

Part-time staffing needs change before and during events. Availability, shift trades, late arrivals, and demand affect the schedule. A small group currently handles much of the coordination and holds much of the knowledge needed to make staffing decisions.

Our proposed tool will help establish the staffing plan earlier, identify uncertainty before the event, and prepare qualified backups and agreed responses. When conditions change, the tool will present the next available backup option so managers can act on a prepared plan.

## 3. Guiding Principles

Our approach will give managers real-time visibility and ready options as conditions change, helping them feel prepared throughout each event rather than constantly responding to emergencies.

| Prevent | Prepare | Pivot |
|---|---|---|
| The tool will help reduce avoidable staffing gaps. | The tool will show staffing readiness before an event. | The tool will support a prepared response when conditions change. |
| Employees will submit availability and request trades before the cutoff. Managers will review and publish the schedule. | Managers will confirm assignments, communicate the plan, review unresolved gaps, and arrange qualified backups. | Managers will review the staffing issue, available backups, and required approvals before confirming a change. |
| **Output:** an approved staffing plan. | **Output:** a shared readiness view and backup plan. | **Output:** a confirmed and recorded change. |

## 4. Discovery

Our team will observe managers during a live event and document how they create schedules, communicate assignments, and resolve staffing changes.

We will review the current tools, handoffs, approval responsibilities, and coverage rules to understand what works well and what needs improvement. With Operations and IT, we will confirm ABI's role, supported interfaces, and the owner of each record.

Our team will deliver an agreed workflow map, prioritized scope, baseline measures, and a plan for integration and access.

## 5. Experience & Solution Design

Our team will design the manager and employee workflows with the people who use them. The prototype will cover availability submissions, schedule reviews, trade requests, readiness checks, and responses to staffing gaps.

We will test whether users can complete these tasks with little explanation. We will also take into consideration communication channels, response deadlines, access permissions, and an alternative for staff who cannot use the chosen interface.

Our team will deliver a prototype based on the specifications described below.

## 6. Prototype & Pilot

Our team will target a working prototype within 90 days of the agreed start date. It will demonstrate the agreed workflow with representative data and the level of ABI integration available to us. Production rollout will follow separate review and acceptance.

We will pilot the tool with selected managers and employees in one department and workflow. Before the pilot, we will confirm access, support, training, and fallback arrangements. We will use the pilot and user acceptance testing to reduce disruption and support adoption before broader rollout.

## 7. Learning Cycles & Progressive Automation

Our team will begin with recommendations that managers review and approve. After each event, we will use staffing issues, rejected suggestions, staff responses, and record mismatches to improve the workflow and decision rules.

We will introduce automation only after observed use demonstrates process reliability and the Magic authorizes the change. Each automated process will have an owner, acceptance criteria, monitoring, and a way to pause it. A change log will show what changed, who changed it, and when. Automation will not silently relax staffing requirements.

## 8. User Acceptance & Rollout

Our team will work with the Magic to agree on required tasks and acceptance evidence. We will include organizational representatives, managers, and employees in this review. We will test routine work, unavailable backups, declined offers, late replies, conflicting updates, and connection outages.

We will agree on formal user acceptance testing (UAT) timing relative to the pilot. Before broader rollout, we will obtain stakeholder acceptance, train users, and document support and escalation procedures. We will expand use in agreed stages.

## 9. Integration & Architecture

During discovery, we will establish the deployment, available data, read/write permissions, update timing, and payroll responsibilities with ABI and the Magic's IT team.

We will assess whether to extend or replace existing scheduling functionality. HR/payroll will remain the system of record for its agreed data. If scheduling moves into the new tool, we will establish one authoritative schedule and an exchange process that avoids competing versions.

We will use supported interfaces or an agreed file exchange. The tool will show when data was last updated, flag failures, and check that accepted changes reached the intended record. Staff acceptance, arrival, and approved time will remain separate records; accepting a shift will not create payable hours.

Our team will develop the initial build and prototype within BrightDesk's environment to limit exposure to the Magic's systems. Once the prototype is approved, we will work with the Magic's IT team on deployment within its systems where appropriate.

## 10. Success Measures

Our team will measure the current process and agree on targets with the Magic. We will compare similar events using consistent definitions and the measures below.

| Measure | What to track |
|---|---|
| Attendance and coverage | Verified no-shows, late arrivals, and minutes a required post is uncovered. |
| Exception response | Time from a verified gap to staff acceptance, with physical arrival tracked separately. |
| Schedule stability and readiness | Changes after the trade cutoff; qualified assignments, pending replies, open posts, and agreed backup coverage. |
| Manager effort | Time spent coordinating changes and correcting records. |
| Communication | Delivery, replies by the deadline, and unresolved follow-ups. |
| Adoption and usability | Task completion, active use, and manager/employee feedback. |
| Record quality and cost | ABI mismatches, time-review exceptions, and added labor or standby cost. |

### Value, in your numbers

We won’t guess at savings. We’ll measure them with you.

- **Manager time:** hours spent on day-of changes and record fixes, at your agreed rate.
- **Coverage:** minutes a required post goes uncovered, and what that gap costs you.
- **Labor spend:** overtime, premium pay, and standby used to fill gaps, before and after the pilot.

Your data, your rates, your approval before any figure is reported.

If we include a readiness score, we will explain how it is calculated. We will report time saved as available staff capacity and will not present it as guaranteed cash savings.

## 11. Software Development Life Cycle

Our team follows a structured software development life cycle (SDLC). We will target a prototype within 90 days, subject to scope, access, and team availability, and confirm rollout timing during discovery.

| Phase | Deliverable | Acceptance point |
|---|---|---|
| Planning and analysis | Current workflows, requirements, scope, and access plan. | We will agree on priorities with the Magic. |
| Design | Proposed workflows, architecture, and interface prototype. | Users and IT will review the design. |
| Development | Working prototype and iterative builds. | We will demonstrate the agreed functions. |
| Testing | Functional tests, controlled pilot, and user acceptance. | Stakeholders will review results and approve readiness. |
| Deployment | Integration, training, handoff, and staged rollout. | The Magic will approve production use. |
| Maintenance | Agreed support, fixes, and improvements. | We will review changes and results with the Magic. |

We will agree on deliverables and acceptance criteria for each milestone. Our team and the Magic will review progress before proceeding. Automation will require proven process reliability and approval.

## 12. Partnership & Pricing Discussion

Following the event's guidance, this proposal focuses on the product and how we would deliver it. If the Magic would like to explore it further with BrightDesk, we will discuss pricing in a follow-up meeting.

**Reusable functionality.** Our team will retain the right to reuse, package, and commercialize general-purpose components and functionality. This reuse will exclude the Magic's data, branding, and confidential information.

**Delivery and handoff.** We will provide the agreed software, documentation, training, and handoff. The final agreement will define the Magic's rights to operate and maintain the solution, BrightDesk's reuse rights, and each party's responsibilities.

## 13. Functional Requirements Ideation

Our team proposes the ideas below as a starting point for the product. During discovery, we will prioritize them with the Magic and agree on scope and acceptance criteria.

| ID | Requirement | Expected behavior |
|---|---|---|
| FR-01 | Availability | Employees will submit and update availability for the relevant event or period. Managers will see missing responses and changes. |
| FR-02 | Scheduling | The tool will create or receive schedules, check coverage and eligibility, publish schedules, and retain the approved version. We will confirm scheduling ownership during discovery. |
| FR-03 | Controlled trades | Managers will set trade windows and cutoffs. The tool will check both assignments against agreed rules and approvals, confirm trades, and route late requests for review. |
| FR-04 | Readiness | Managers will see qualified assignments, pending confirmations, gaps, and backup coverage. Any score will include its calculation, source data, and missing information. |
| FR-05 | Contingency coverage | Managers will be able to arrange backup coverage and see eligibility, availability, replies, and readiness to report. We will agree on standby policies and costs with the Magic. |
| FR-06 | Staffing exceptions | Managers will see verified call-outs, arrival issues, changed staffing needs, and qualified replacements, including posts they would leave. The tool will escalate unresolved gaps. |
| FR-07 | Communication | Staff will receive assignments and changes through agreed channels. Managers will be able to track delivery, replies, deadlines, and follow-up separately. |
| FR-08 | Decisions and automation | Recommendations will remain pending until required approvals and staff responses are complete. We will introduce automation only after process reliability is proven and authorization is given. |
| FR-09 | ABI and time records | The tool will exchange supported data, record accepted changes, flag stale or failed updates, and reconcile records. Arrival and actual-time approval will remain separate. |
| FR-10 | Access and traceability | We will limit access by role and employer. The tool will record who proposed, approved, accepted, or corrected a change, and when. Each failure will have an owner and fallback. |

**Replacement example.** Our demo shows Jordan canceling a North gate shift from 5-8 PM. A manager approves an offer to Ava, a qualified backup. After Ava accepts, her card replaces Jordan's and shows "Confirmed" and "Replacement." Arrival and ABI confirmation remain separate checks.

We will use AI-driven development as a delivery method. We will address security and data handling in the architecture.

## Website examples

The interactive website uses fictional staff, counts, timing, and rules to explain the proposed workflow. It sends no messages or ABI updates. The examples do not establish live integration, client acceptance, or measured results.