Internal platform · Asset lifecycle · Multi-campus operations
Multi-Campus Asset Management System
The product was not an inventory list. It was a continuously reconciled account of identity, location, responsibility, condition and history.
Every product visual is labelled by provenance, so original work is never confused with a portfolio-created explanation.
A genuine working document, wireframe, screenshot or output that can be shown publicly.
A recreated product view grounded in the original work, using synthetic or anonymised information.
A simplified model created for this portfolio to explain system behaviour, workflow or product logic.
The operational problem behind an inventory request
The spreadsheet could say an asset existed. It could not reliably explain where it was, who held it, what condition it was in or how it reached that state.
Internal platforms · Asset lifecycle · Workflow systems · Multi-campus operations
Technology assets moved between campuses, students, employees, remote locations, storage and repair. Each movement changed more than one piece of data. The product challenge was to translate physical-world custody, intermediate states and recurring verification into system behaviour that operations could execute consistently.
The physical object and the digital row could drift apart.
A shared name or serial number was not enough for fast field verification. Each item needed a scannable digital identity linked to one authoritative record.
Location, responsibility and condition were being treated as one answer.
An asset could be active, assigned to an employee and physically remote at the same time. Those dimensions had to remain independent.
A location edit erased the operational hand-off.
Inter-campus transfers required dispatch, in-transit, receiving and reconciliation—not an instantaneous change of campus.
One asset · four independent truths
A reliable record had to answer four questions at the same time.
The central data-model decision was to stop using one field as a proxy for the whole asset. Identity, location, responsibility and condition could change independently while remaining connected through lifecycle history.
Unique asset record · barcode · category · serial information
Campus · remote · storage · repair location
Student · employee · campus custodian · receiving owner
Active · needs attention · repair · storage · unavailable
Three product decisions that made the record trustworthy
The product had to model physical reality instead of making it look instantaneous.
Each workflow was designed around the moment where a spreadsheet usually loses truth: when responsibility changes, when movement is incomplete, or when the digital record has not been checked against the object.
Separate identity, location, responsibility and condition.
The record model avoided collapsing several operational questions into a single status field. This made it possible to represent assets that were active but remote, assigned but under repair, or present at a campus while awaiting hand-over.
Treat every inter-campus transfer as a transaction.
Movement became an auditable workflow with dispatch, in-transit, receiving and reconciliation states. The destination did not become authoritative until the receiving side confirmed the hand-over.
Build verification into normal operations.
Periodic barcode scanning and ownership or condition checks compared the physical item with the system record. Exceptions could then be investigated instead of remaining hidden inside ageing spreadsheets.
From operational policy to organisation-wide production
I translated asset policy and physical operations into explicit product rules.
My scope covered stakeholder discovery, Release 1 boundaries, PRDs and functional specifications, workflow states, permissions, exception handling, prioritisation, UX and engineering coordination, pilot planning, training and rollout. The first release deliberately focused on IT assets already under NavGurukul control so the team could establish a coherent production system before expanding scope.
Stakeholder discovery and operational policy mapping
Release 1 scope and asset-class prioritisation
Record model, workflow states and exception handling
Barcode and mobile-verification behaviour
Pilot, training and organisation-wide rollout
Production feedback and lifecycle refinement
Deliver a coherent system of record for assets already under organisational control before expanding into procurement, ticketing and broader maintenance workflows.
Observed operational outcomes
Production evidence
What changed when asset movement became an explicit workflow.
Replaced fragmented spreadsheet tracking with a shared production workflow.
Improved visibility into asset location, responsibility and condition across campuses.
Improved transfer accountability through explicit dispatch, transit, receiving and reconciliation states.
Made physical verification easier and helped surface missing or unaccounted assets.
Provided leadership with consolidated inventory and lifecycle visibility.
The system was piloted at Sarjapur, rolled out organisation-wide and remained operational. Outcomes are presented as observed improvements in visibility, accountability and verification; no unsupported efficiency percentages are used.
The interface visuals in this public case are portfolio reconstructions using synthetic records. Student, employee, asset and campus identifiers from the production system are not published.
What the work changed in how I think
Systems of record are promises about reality, not databases of last-known values.
The best MVP is often defined by exclusion.
Narrowing Release 1 to assets already under organisational control created a coherent system of record instead of a partial procurement, ticketing and maintenance suite.
Physical workflows need intermediate states.
Dispatch and receipt do not happen at the same moment. The data model has to represent the operational gap.
Ownership, location and condition are different facts.
Combining them into one field makes the interface simpler but the system less truthful.
Verification is a product capability, not a clean-up exercise.
Recurring reconciliation keeps the digital record connected to the physical asset over time.