The Technician Burnout Console is a real-time operations dashboard that surfaces technician health risk before it becomes a retention problem. It calculates a composite burnout score for every technician by combining billable utilization, overtime hours, after-hours sessions, and ticket velocity data pulled from ConnectWise PSA and NinjaRMM.

The dashboard gives operations managers a single screen to identify who is at critical risk, who has available capacity to absorb redistribution, what skills gaps are creating concentration risk, and what specific actions will reduce burnout before a technician quits. It is designed for weekly manager review and monthly leadership reporting.

Seven KPI tiles run across the top of the console below the API banner. They calculate across the full technician dataset and update when the page refreshes. Color rules match the burnout scale — red above critical thresholds, orange elevated, green healthy.

The API banner runs between the hero section and the KPI strip. It shows six data source nodes, each with a live/mock status dot, the data value currently loaded, and the exact API endpoint being called. This lets any engineer verify at a glance which data is live vs simulated.

The technician grid is the primary view — a card for every technician in the dataset. Cards are ordered by burnout score descending by default. Each card shows the risk badge, burnout score with a gradient fill bar, six stat tiles, and the first three certifications. Clicking any card opens the Deep Dive panel for that technician.

Clicking any technician card expands a full-width Deep Dive panel below the grid. The panel shows four sub-sections for the selected technician. Clicking the same card again or the × button collapses it.

The heatmap section shows an 8×N grid — 8 weeks of data (columns) for every technician (rows). Each cell is color-coded by utilization percentage. Cells with a red border indicate weeks where that technician logged overtime.

Reading the heatmap across a row shows a single technician's trajectory over 8 weeks. A row that transitions from yellow to orange to red over 8 weeks (like Marcus J. in the demo) shows exactly when over-utilization began and how quickly it escalated. Reading down a column shows the team's overall load in a specific week — useful for identifying whether overload is systemic (whole column red) or isolated to specific individuals.

Five aggregate charts appear in the Analytics section, giving a team-wide view that complements the individual technician data in the grid and heatmap.

The Skills Matrix section is a table of every technology stack in the environment vs the certifications and technicians covering it. It flags skill gaps, SPOF (single point of failure) situations, and demand vs coverage mismatches.

Three filter controls sit between the KPI strip and the technician grid. All filters apply simultaneously and update the grid in real time without a page refresh.

The left sidebar navigation scrolls to each console section: Capacity & Risk Status, Utilization Heatmap, Team Trends, and Skills Matrix. The top navigation bar provides the same section links plus a back link to the MSP Command Center index.

Each technician object in the techs array uses this schema. Understanding the schema is required before wiring live API data, as the mapCWMember() function (C2) must return objects that match this shape exactly.

The console runs fully in demo mode with no prerequisites. For live data, the following are required before wiring begins.

ConnectWise provides the core data for the burnout score: time entries (utilization, overtime), service tickets (queue depth, velocity, timestamps for after-hours detection), and member records (names, roles, teams).

NinjaRMM provides device count data per organization — used for workload context in the API banner. It is secondary to the ConnectWise data and can be left in mock/connected state while CW data is wired first.

Before wiring live APIs, update the static techs array to reflect your actual team. This ensures the demo runs with realistic data for your environment and the filters (team names, role labels) match your org structure.

• 1
  Replace technician names and roles.Edit the techs array at the top of the script block. Each object needs name, role, team, and initial values for burnout, util, ot, ah, tickets, queue.
• 2
  Confirm team names match the filter dropdown.The team filter expects exact string matches: Tier 1, Tier 2, Tier 3, NOC. If your org uses different names (e.g. "L1 Help Desk"), either update the team values in the data or update the dropdown option values in the HTML.
• 3
  Update certifications.The certs array and expiredCerts array are strings. These also feed the Skills Matrix — the skillAreas array references cert names by string match. If you rename a cert, update it in both places.
• 4
  Update the skillAreas array.The Skills Matrix is driven by the skillAreas array below the techs array. Update each entry's techs list (technician names), coverage (cert names), openTickets, and gap flag to match your environment.

The burnout score thresholds and color rules are hardcoded in four places in the script. When wiring live data, you can tune these to match your organization's norms — an MSP with a higher baseline utilization rate may want to shift the "high" threshold from 80% to 85%.

Run through this checklist after wiring live APIs. Demo mode requires no verification — the static data renders immediately on page load.

• ✓
  API banner nodes show correct dot colors. CW Proxy and NinjaRMM nodes should show green dots. Time Entries and Tickets nodes should show green once live — orange means those endpoints are still using mock data.
• ✓
  KPI strip populates with real numbers. If KPI tiles show 0 or — across the board, the techs array is empty — the live data fetch failed. Check the browser console (F12) for the fetch error.
• ✓
  Technician cards render in the grid. At least one card should appear. If the grid is empty but no JS error appears, check that the team names in your live data match the filter dropdown values exactly.
• ✓
  Clicking a card opens the Deep Dive. The utilization trend chart should render. If the chart area is blank, the history array in the technician object is empty — verify the 8-week history calculation in your mapper function.
• ✓
  Heatmap renders with correct technician rows. If the heatmap is empty, the techs array has no items with populated history arrays.
• ✓
  All five analytics charts render. If any chart canvas is blank after switching to the Analytics section, the chart was destroyed and not re-initialized. Check that renderCharts() is called on page load and not before the canvas elements exist in the DOM.
• ✓
  Skills matrix gaps are accurate. If no GAP flags appear, check that cert names in the techs[].certs arrays match the strings in skillAreas[].coverage exactly — including spacing and capitalization.
• ✓
  Filters correctly narrow the grid. Select "Critical Burnout" — only technicians with burnout ≥80 should appear. If all cards still show, the risk field in the technician data objects is not being set by calcRisk().