A live planning workspace that turns licensed, masked helpdesk records into transparent weekday demand and priority resolution baselines without pretending to automate staffing decisions.
Support Demand and Resolution Decision Briefing
What can historical support signals justify before a staffing conversation?
They can frame a transparent weekday demand reference and a separate priority resolution-risk prompt. They cannot decide staffing adequacy without live arrivals, backlog, schedules, and operating constraints.
Support leaders can frame one staffing-meeting question from two independent historical baselines, inspect the latest observed demand window, and make missing live inputs visible before discussing coverage.
Analytics Engineering
Built a PostgreSQL-backed support planning product over licensed masked helpdesk records, separating 2019 to 2021 training from a fixed 2022 holdout and reporting 26.3% demand WAPE with 92.6% interval coverage.A support operations leader preparing a staffing or service-risk discussion.
Context and stakes
The decision context behind the system.
The demand baseline is directionally useful for a planning conversation, with 26.3% held-out WAPE and 92.6% interval coverage. The resolution baseline is much weaker at 767.7 hours MAE despite 98.5% interval coverage, so the product presents it only as a risk prompt. The briefing makes those limitations and the missing live inputs visible before any staffing discussion.
Support planning teams need a shared historical reference without turning incomplete evidence into an automated staffing answer.
Approach
A bounded approach shaped by the published constraints.
They can frame a transparent weekday demand reference and a separate priority resolution-risk prompt. They cannot decide staffing adequacy without live arrivals, backlog, schedules, and operating constraints.
Design constraints
- No live arrivals, backlog, staffing schedules, skill mix, shrinkage, customer outcomes, or SLA commitments are connected.
- The weekday-only demand baseline omits holidays, trend, events, product changes, and richer seasonal effects.
- Long-tailed resolution durations make the priority baseline unsuitable for case-level prediction.
- The public demonstration is not validated for production staffing decisions or operational service levels.
Decision journey
The system moves through an inspectable sequence.
Each stage below comes from the published project manifest.
- Stage
Validate the licensed source
Licensed masked Mendeley records remain outside Git
- Stage
Load masked ticket records
Python validates source shape, dates, and deterministic sanitization
- Stage
Build training-only weekday demand
PostgreSQL separates raw contracts from curated aggregate tables
- Stage
Evaluate both baselines against
A held-out evaluation measures transparent descriptive baselines
- Stage
Serve aggregate-only evidence and
Flask and Jinja serve the decision briefing behind Caddy HTTPS
Interactive architecture
The published architecture, made interactive.
The product keeps the evidence path intentionally small. A deterministic Python ingestion contract validates licensed masked records, PostgreSQL creates training-only weekday and priority baselines, and a fixed 2022 holdout qualifies their limits. Flask reads only curated aggregates. The briefing pairs a weekday demand reference with a separately selected priority resolution reference, shows recent observed variation, and asks the user to confirm live operational inputs before discussing coverage.
Drag to pan · use controls to zoom · select any stageRead the architecture as text
- Licensed masked Mendeley recordsStage 1 · Python
Licensed masked Mendeley records remain outside Git
- Python validates source shape,Stage 2 · Flask
Python validates source shape, dates, and deterministic sanitization
- PostgreSQL separates raw contractsStage 3 · PostgreSQL
PostgreSQL separates raw contracts from curated aggregate tables
- A held-out evaluation measuresStage 4 · Docker Compose
A held-out evaluation measures transparent descriptive baselines
- Flask and Jinja serveStage 5 · AWS Lightsail
Flask and Jinja serve the decision briefing behind Caddy HTTPS
Pivotal decisions
Technology choices recorded with their trade-offs.
These choices are derived from the project’s published decision record.
Use Transparent grouped means within the published boundary
Weekday demand and priority resolution means are inspectable reference points for a stakeholder conversation.
- Constraints
- Weekday and priority means are legible and reproducible but omit seasonality beyond weekday, backlog, staffing, skill mix, shrinkage, customer outcomes, and SLA commitments.
- The public demo reuses one small Lightsail instance, which keeps the approved monthly cost at USD 7 but provides no uptime guarantee.
- The sslip.io hostname provides valid HTTPS without a separately owned domain, but it remains tied to the static public IP.
- Alternatives
- A more complex forecasting model
- Criteria
- Fit for the stated scope · Inspectable evidence · Explicit operating boundary
- Selected
- Transparent grouped means
- Why
- Weekday demand and priority resolution means are inspectable reference points for a stakeholder conversation.
- Trade-off
- The simple baselines omit richer seasonality and operational context, which the product states explicitly.
- What supported it
- 26.3% Held-out daily-demand WAPE: Weekday means trained on 2019 through 2021 and evaluated across 2022.
- Revisit when
- Add time-indexed operational arrivals and backlog only after their ownership, latency, and disclosure contracts are approved.
Use PostgreSQL curated serving tables within the published boundary
Versioned migrations and aggregate-only reads keep ingestion, evaluation, and public serving boundaries distinct.
- Constraints
- Weekday and priority means are legible and reproducible but omit seasonality beyond weekday, backlog, staffing, skill mix, shrinkage, customer outcomes, and SLA commitments.
- The public demo reuses one small Lightsail instance, which keeps the approved monthly cost at USD 7 but provides no uptime guarantee.
- The sslip.io hostname provides valid HTTPS without a separately owned domain, but it remains tied to the static public IP.
- Alternatives
- Read a flat file directly in the web process
- Criteria
- Fit for the stated scope · Inspectable evidence · Explicit operating boundary
- Selected
- PostgreSQL curated serving tables
- Why
- Versioned migrations and aggregate-only reads keep ingestion, evaluation, and public serving boundaries distinct.
- Trade-off
- A database adds operational weight but makes data contracts and public exclusions testable.
- What supported it
- 92.6% Demand interval coverage: Observed 2022 daily demand inside a nominal 95% historical interval.
- Revisit when
- Replace the descriptive baselines only when a challenger clears prespecified held-out quality and calibration gates.
Use Server-rendered Flask and Jinja within the published boundary
Native selects and semantic HTML support the small decision workflow without a frontend framework or client data API.
- Constraints
- Weekday and priority means are legible and reproducible but omit seasonality beyond weekday, backlog, staffing, skill mix, shrinkage, customer outcomes, and SLA commitments.
- The public demo reuses one small Lightsail instance, which keeps the approved monthly cost at USD 7 but provides no uptime guarantee.
- The sslip.io hostname provides valid HTTPS without a separately owned domain, but it remains tied to the static public IP.
- Alternatives
- A client-rendered dashboard framework
- Criteria
- Fit for the stated scope · Inspectable evidence · Explicit operating boundary
- Selected
- Server-rendered Flask and Jinja
- Why
- Native selects and semantic HTML support the small decision workflow without a frontend framework or client data API.
- Trade-off
- The interface favors a bounded meeting-preparation flow over open-ended dashboard composition.
- What supported it
- 767.7 hours Held-out resolution-time MAE: Priority means trained on 2019 through 2021 and evaluated across resolved 2022 records.
- Revisit when
- Separate the application and database tiers if concurrency, recovery objectives, or uptime requirements exceed the single-instance demonstration boundary.
Use AWS Lightsail with Caddy within the published boundary
One existing budgeted instance supports a stable static IP, valid HTTPS, and reversible container releases.
- Constraints
- Weekday and priority means are legible and reproducible but omit seasonality beyond weekday, backlog, staffing, skill mix, shrinkage, customer outcomes, and SLA commitments.
- The public demo reuses one small Lightsail instance, which keeps the approved monthly cost at USD 7 but provides no uptime guarantee.
- The sslip.io hostname provides valid HTTPS without a separately owned domain, but it remains tied to the static public IP.
- Alternatives
- Provision separate managed application and database services
- Criteria
- Fit for the stated scope · Inspectable evidence · Explicit operating boundary
- Selected
- AWS Lightsail with Caddy
- Why
- One existing budgeted instance supports a stable static IP, valid HTTPS, and reversible container releases.
- Trade-off
- The single-instance demonstration has no production uptime or scaling commitment.
- What supported it
- 0 raw rows Deployed ticket-level records: The live database contains daily, weekday, and priority aggregate tables only.
- Revisit when
- Move from sslip.io to an owned domain only after domain authority and recurring cost are explicitly approved.
Results and evaluation
Measured results within the disclosed evaluation boundary.
- Method
- Fixed temporal holdout with weighted absolute percentage error.
- Meaning
- The transparent demand baseline is useful for discussion but leaves substantial error.
- Limitation
- No live arrivals, backlog, staffing schedules, skill mix, shrinkage, customer outcomes, or SLA commitments are connected.
Limitations and next steps
Useful evidence, bounded claims.
What this does not prove
- No live arrivals, backlog, staffing schedules, skill mix, shrinkage, customer outcomes, or SLA commitments are connected.
- The weekday-only demand baseline omits holidays, trend, events, product changes, and richer seasonal effects.
- Long-tailed resolution durations make the priority baseline unsuitable for case-level prediction.
- The public demonstration is not validated for production staffing decisions or operational service levels.
- The single Lightsail instance and free sslip.io hostname have no uptime or owned-domain commitment.
- Automated accessibility and responsive checks do not replace a full assistive-technology review.
What I would do next
- Add time-indexed operational arrivals and backlog only after their ownership, latency, and disclosure contracts are approved.
- Replace the descriptive baselines only when a challenger clears prespecified held-out quality and calibration gates.
- Separate the application and database tiers if concurrency, recovery objectives, or uptime requirements exceed the single-instance demonstration boundary.
- Move from sslip.io to an owned domain only after domain authority and recurring cost are explicitly approved.
This public demonstration uses aggregate derivatives of licensed, masked helpdesk records. It is not a production forecast, staffing recommendation, SLA commitment, causal analysis, or customer outcome claim.
Explore the rest of the work