Urban Pathways' intake process relied on spreadsheets and the intake coordinator's memory. There was no shared view of the intake backlog, case stage, or follow-up history, and routine communications depended on manual follow-up.The opportunity was to turn an individual-dependent workflow into a shared intake system without forcing the organization into a generic CRM structure.
I mapped the coordinator's existing intake process and translated it into five product requirements:
01 · Backlog:
A single view of people currently waiting for intake.
02 · Stage Tracking:
A clear indication of where each case sits in the intake process.
03 · Progress Log:
A persistent record of activity and case history.
04 · Automated Follow-Up:
Routine communications that do not depend on the coordinator remembering to send them.
05 · Feedback Loop:
Visibility into responses and where cases stall after follow-up.
Before building, I also reviewed the proposed workflow with compliance to confirm there was no existing CRM or internal system conflict and secure approval to workshop the prototype with the intake coordinator.
Product Decisions
Intake
Each person entering intake receives a single record containing their current stage and running progress history. This creates a shared source of truth while making the active backlog visible at a glance.
Workflow & Compliance
Rather than adapting the organization to a generic CRM workflow, the prototype was structured around the coordinator's actual intake process. This was the primary reason for pursuing a custom build rather than adopting an off-the-shelf workflow. Compliance review happened before implementation. The review confirmed that no competing internal system existed and cleared the prototype for pilot use.
Follow-Up
Routine communications are triggered through the system rather than relying on individual memory. The feedback loop captures what happens after outreach, making it possible to see responses and identify where cases are getting stuck.
Deployment Constraint
The prototype reached approval to pilot, but implementation depended on access to the coordinator's existing spreadsheets for data population and testing. That dependency was never fulfilled, preventing the pilot from moving forward.
The deployment lesson was straightforward: data access is a product dependency, not a post-build detail. In future implementations, access requirements and ownership would be established before prototype completion.
Results
Aperture translated a memory- and spreadsheet-dependent intake process into a structured CRM prototype with:
A centralized intake backlog, Case-stage visibility, Persistent progress history, Automated follow-up, Post-outreach feedback tracking, Compliance approval for pilot
