UrbanIQ
Product ManagerInstitutional Complaint & Document Management Platform
UrbanIQ is an AI-assisted complaint and document management platform for institutional workflows. I was the Product Manager on a team of ten, and I owned the roadmap from PRD through deployment.
It went into live use and processed 4,000+ real submissions. That number is the reason this project matters more than anything else I’ve built: the specs were tested by actual people with actual complaints, and afterwards there was enough data to find out where the specs were wrong.
- Build available on request
Submission
requester
AI classification
on ingest
Handler queue
auto-routed
Staged approval
through handlers and administrators
SLA analytics
by department
01 / 09
Problem
Institutional complaint and document handling puts three roles — requester, handler and administrator — on the same process with different requirements of it. Each one needs something the others don’t, and each one’s needs constrain the others’.
That is what makes it a product problem rather than a software problem. Building three tools is easy; building one system whose data means the same thing to all three is not. Routing, resolution time and departmental SLA performance all depend on getting that reconciliation right first.
02 / 09
Goal
Product goal
One system where all three roles get what they need from the same data, submissions route themselves, and the bottlenecks become visible.
Definition of done — the actual hard part
Reconcile three roles’ requirements — requester, handler, administrator — into one prioritized backlog with acceptance criteria precise enough to build against.
Measurable targets
- Reduce time from submission to resolution.
- Route submissions without manual triage.
- Make SLA performance visible by department.
03 / 09
Architecture
Role-based access across three user types
Requester, handler and administrator each see a different product built on the same underlying records. Getting this right at the data layer was what allowed a single system to serve three conflicting sets of expectations.
AI-based classification on ingest
Incoming submissions are classified by content and auto-routed to the correct handler queue, replacing manual triage. This is the piece that removed the manual step at the front of the process.
Approval workflow
A staged approval path through handlers and administrators. The order of these stages turned out to be the single highest-leverage variable in the whole system — see Technical Decisions.
Analytics layer
Python and pandas for exploratory analysis, Metabase for the dashboards that made SLA breach patterns visible by department.
Screens pending — walkthrough available on request
04 / 09
Key features
AI complaint classification
Reads submission content and auto-routes to the right queue
ImpactRemoved the manual triage step at the front of the process
Three role-based experiences
Requester, handler and administrator views over shared records
ImpactOne system instead of three, with 15+ user stories reconciling the conflicts
Staged approval workflow
Structured path from submission to resolution
ImpactReordering these stages cut resolution time 30% in load testing
Document management
Institutional document requests handled in the same pipeline as complaints
ImpactOne platform covering both, rather than a complaint tool and a document tool
SLA analytics by department
Metabase dashboards over 4,000+ submissions
ImpactSurfaced breach clustering nobody had predicted, which changed prioritization
05 / 09
Technical decisions
Reordering the approval workflow instead of optimising each stage.
The instinct with a slow process is to make each step faster. The EDA said the delay wasn’t in any single stage — it was in the sequence, where work waited for an approval that didn’t need to come first. Reordering the stages cut resolution time 30% in load testing. It’s the best return I’ve gotten from a change that added no features at all.
AI classification over a routing rules engine.
Rules would have been more predictable and easier to debug. But a rules engine over free-text complaints becomes a keyword list that fails on anything phrased unexpectedly — which is a lot of real complaints. Classification handled the variance. The cost was accepting probabilistic routing in a workflow where being wrong has a human on the other end, so misroutes had to be recoverable by design rather than prevented.
One system with role-based views over three separate tools.
Three tools would have shipped faster and each role would have gotten exactly what it asked for. But the administrator’s throughput view is only meaningful if it’s reading the same records the handler is closing. Splitting the system would have split the truth.
Reconciling all three roles before writing any stories.
I could have written each role’s stories in that role’s own language and discovered the contradictions during QA. Instead I reconciled the requirements across all three roles first, which is why the 15+ prioritized user stories carried acceptance criteria precise enough to build against. It was slow, and it was the highest-value work on the project.
Running EDA after launch and letting it change the roadmap.
The analysis on 4,000+ submissions wasn’t a report for stakeholders — it fed back into prioritization. SLA breaches clustered by department in ways the original roadmap hadn’t anticipated, and the roadmap changed.
06 / 09
Challenges
Three roles, one set of acceptance criteria.
Requester, handler and administrator each come at the same process from a different position, and each has a different reason to care about it. Reconciling those three sets of requirements into 15+ prioritized user stories with acceptance criteria was the central product problem — the software was comparatively easy afterwards.
Coordinating ten people as a student.
Leading a 10-person student build is not the same as managing a team — alignment has to come from written specs clear enough to be self-executing, because nothing else is enforcing it. That is the main reason my PRDs and acceptance criteria got sharp.
Probabilistic routing in a process with real consequences.
AI classification will misroute. When the misrouted thing is somebody’s complaint, “the classifier is usually right” is not a defence. Designing for recoverable misroutes rather than trying to eliminate them was the necessary reframe.
Measuring an improvement I couldn’t measure in production.
The 30% resolution-time reduction was measured in load testing. Load testing isn’t live behaviour, and I state it that way every time. Being able to say what a number does and doesn’t cover is part of the number.
07 / 09
Lessons learned
The hardest part of product is definitional, not technical.
Ten people, three roles, one working platform — and the bottleneck was never engineering. It was getting agreement on what a word meant. I now treat “do all stakeholders mean the same thing by this?” as the first question on any spec.
Sequence beats speed.
A 30% reduction in load testing came from reordering stages, not from making anything faster. Look at the shape of a process before optimising its parts.
Written specs are the instrument, not the artefact.
On a 10-person student build, the only reliable instrument is a document precise enough that nobody needs to ask what it meant. Writing to that standard made me better at the job than any amount of coordinating in meetings would have.
Post-launch analysis is part of the product, not a report about it.
Running EDA on 4,000+ submissions and changing the roadmap because of it is the loop that makes prioritization honest. Without it, prioritization is just confident guessing.
Qualify your numbers or lose the room.
“Cut resolution time 30% in load testing” is a weaker sentence than “cut resolution time 30%” and a far stronger position to defend. The qualifier is what makes the claim worth something.
08 / 09
Future improvements
Measure the resolution-time improvement in production rather than load testing, and publish the difference between the two.
Track classification accuracy over time and build an explicit correction loop so misroutes retrain routing rather than just getting fixed.
Give requesters proactive status updates instead of a page they have to check — most of the requester’s frustration was informational, not procedural.
Turn the department-level SLA findings into alerting rather than a dashboard someone has to open.
Revisit the approval sequence with production data now that the load-test finding is known to matter.
09 / 09
Technologies used
Named in the résumé for this project
- Python (pandas)
- Metabase
- AI Classification
- Exploratory Data Analysis
- PRD Authoring
- User Stories & Acceptance Criteria
- Roadmapping
In the global skills list, not attributed to UrbanIQ
- KPI Definition
- Agile & Scrum
- Jira
- Jupyter
- NumPy
- matplotlib