Scott CampbellAnalytics, BI, Automation

Operations Request Tracker

Request intake and tracking system designed to reduce lost follow-up, improve status visibility, and give leaders a reliable view of open work.

Problem

Operational requests lose context when intake, approvals, status updates, and reporting are split across messages, spreadsheets, and manual follow-up.

Teams need a single view of what was requested, who owns it, where it sits, and which work needs attention.

Users or audience

The system supports requestors, reviewers, owners, and leaders who need status visibility without searching through message threads.

Solution

The tracker converts requests into structured records, routes approvals, tracks ownership, and exposes status reporting for managers and requestors.

The design focuses on making the workflow clear enough to use daily while preserving the reporting structure needed for recurring review.

Architecture

Request intakeStructured form capture and required fields
↓
Approval workflowRouting, decision capture, and notification steps
↓
Tracker listStatus, owner, aging, priority, and category fields
↓
Reporting viewsOpen work, overdue items, throughput, and category trends

Data flow

A request enters through structured intake, receives category and priority fields, moves through approval or ownership assignment, and becomes part of status reporting for open work and aging.

Tools used

  • SharePoint
  • Power Platform
  • Power Automate
  • Approvals
  • Operational reporting

Key features

  • Structured request intake.
  • Approval and notification workflow.
  • Owner, aging, category, and priority tracking.
  • Views for open work, overdue items, and workload trends.

Evidence

Internal system, public case study only. Public evidence uses sanitized diagrams and written workflow notes.

Tradeoffs and constraints

The tracker prioritizes clarity and consistent usage over complex customization. Public screenshots are withheld, so the case study emphasizes structure, workflow logic, and reporting intent.

TrackableRequests become structured records.
AccountableOwnership and status are visible.
ReportableLeadership can scan workload and bottlenecks.

Limitations

Confidential records and production screenshots are not shown. The public page focuses on the system pattern and the problem-solving approach.

What I would improve next

I would add better SLA reporting, role-specific dashboards, and trend analysis around request category, owner workload, and aging.

Back to Projects