Sometimes the performance problem isn't a training problem.
An end-to-end framework connecting request intake, workflow management, structured data, human review, and reporting while adapting to real technology and governance constraints.
Conceptual framework visualization. Dashboard values are illustrative; the prototype was tested with synthetic, non-confidential data.
THE CHALLENGE
The problem was bigger than a training intervention.
Community-engagement work can generate information across requests, scheduling, consultations, documentation, follow-up, outcomes, and reporting. When those activities live in disconnected processes, information becomes harder to manage consistently and harder to turn into useful organizational insight.
The design question became: how can one system capture a request, move it through a consistent workflow, preserve human oversight, and produce structured information that supports reporting?
The question was not“What training should we build?”
→
It became“What system does the work actually need?”
END-TO-END DESIGN
From request to reporting.
Rather than treating intake as a standalone form, the framework connects the full lifecycle.
1
Request
A request enters through an approved intake channel.
2
Intake
The submission becomes a structured workflow case.
3
Route
Fields support categorization, ownership, and routing.
4
Engage
The case moves through review, scheduling, and engagement.
5
Document
Notes, follow-up items, and relevant information are captured.
6
Review
People validate information and confirm categorization.
7
Dashboard
Structured records support operational visibility.
8
Report
Completed information can support deeper analysis.
ITERATIVE DESIGN
The architecture changed. The goal didn't.
01 · Broader architecture
The initial concept explored a multi-platform ecosystem connecting intake, workflow management, automation, structured information, and reporting.
02 · Constraint discovery
Technical, security, and governance constraints affected some planned integration and automation paths.
03 · Asana-native prototype
Rather than forcing an impractical toolchain, the proof of concept was redesigned around capabilities available within Asana while preserving the end-to-end process logic.
Good systems design adapts to the environment without losing sight of the problem it was designed to solve.
WORKING PROTOTYPE
Simplifying the technology without simplifying the thinking.
Asana became the primary environment for public intake, structured case management, workflow stages, status management, rules, due-date logic, documentation, operational visibility, and export.
Synthetic requests were used to test workflow behavior without exposing real organizational or community data.
New Requests
In Review
Scheduling
Scheduled
Engagement in Progress
Follow-Up and Complete
Completed
Seven-stage workflow. Status-driven rules support forward and backward movement so cases can respond to real workflow changes rather than assuming a perfectly linear process.
HUMAN + AUTOMATION
Automate the repetitive. Keep judgment human.
Automation Supports
Case creation
Stage movement
Structured fields
Due-date logic
Routing and status updates
Operational consistency
People Handle
Review and context
Scheduling decisions
Communication
Data validation
Categorization
Quality control
Automation reduces friction. Human oversight protects meaning.
REPORTING ARCHITECTURE
Reporting starts before the dashboard.
Useful reporting depends on what is captured upstream. Intake fields, workflow status, documentation, and human validation were considered as part of the reporting design—not as separate activities added later.
Asana dashboards support operational visibility. CSV export provides a path to Power BI for deeper analysis; Power BI is shown as a downstream reporting destination, not a live automated integration.
Intake
Structured Data
Human Review
Operational Visibility
CSV Export
Power BI Advanced reporting
WHAT THIS PROJECT DEMONSTRATES
Designing beyond the course.
Systems Thinking
Seeing beyond an individual tool or training request.
Performance Analysis
Identifying when the underlying need is structural rather than instructional.
Workflow Architecture
Designing how work moves from request through completion.
Technology Evaluation
Adapting the solution to real technical and governance constraints.
Human-Centered Automation
Using automation for consistency without removing necessary judgment.
Data & Reporting Thinking
Designing upstream information capture around downstream visibility.
The technology was selected to support the workflow—not the other way around.
