Nandankanan
Zoological Park
A 437-hectare park with roughly 250 enclosures and around 200 species — and the first Indian zoo admitted to the World Association of Zoos and Aquariums. We built its admin portal, backend API and mobile application.
- 437ha
- Park area managed
- ~250
- Enclosures
- ~200
- Species
- 1st
- Indian zoo in WAZA
Park figures per Nandankanan Zoological Park public information.
The institution
Nandankanan Zoological Park sits on 437 hectares outside Bhubaneswar in Odisha, India, operated by the state Forest Department. It holds roughly 250 enclosures — around 100 of them open-moated — across approximately 200 species of mammals, birds, reptiles and amphibians.
Its standing is not merely regional. In 2009 Nandankanan became the first zoo in India admitted to the World Association of Zoos and Aquariums. It was the first zoo in the world to breed both white and melanistic tigers, opened India’s first white tiger safari in 1991, and remains the only conservation breeding centre for Indian pangolins anywhere in the world.
The operating problem
A park at this scale runs on records: which animal is in which enclosure, what treatment it received, which beats were patrolled on a given shift, what incidents occurred and how they were resolved. Those records are generated by very different people in very different places — curatorial staff, veterinary teams, field patrols and administrators.
Before the system, those records lived in paper registers and spreadsheets. The information existed, but it could not be seen together — reporting was an exercise in manual compilation, and the operational picture was only ever assembled after the fact. Visibility across the park was poor.
The approach
We built a single platform across three surfaces: an admin portal for office and curatorial staff, a backend API as the shared source of truth, and a mobile application for staff working in the field.
The split matters. Patrol logging and incident reporting are field activities — a system reachable only from a desk would be filled in retrospectively, or not at all. Putting capture on mobile and management on the portal, over one API, keeps a single record set without forcing either group into the other’s workflow.
Analytics dashboards were integrated on top of that shared record, giving forest officers consolidated reporting drawn from live operational data rather than compiled by hand at period end.
How the three surfaces fit together
One shared record behind three ways of working — so field staff, veterinary teams and administrators each use the surface that suits them without the data fragmenting.
The split matters: patrol logging and incident reporting happen away from a desk, so capture sits on mobile while management and reporting sit on the portal — over one API, so there is still only one record set.
What we delivered
The scope spanned service delivery across the park’s core operational functions.
- Admin portal application
- Web application for curatorial, veterinary and administrative staff.
- Backend API
- The shared services layer behind both the portal and the mobile application.
- Mobile application
- Field capture for patrol logging and incident reporting.
- Animal inventory management
- The living collection as a structured register — enclosures, species and individual animals.
- Veterinary management
- Clinical records and treatment history tied to the animal record.
- Out-patient management
- Examination and out-patient workflows for veterinary teams.
- Daily patrol logging
- Beat and route coverage captured by field staff during each shift.
- Incident reporting
- Structured incident capture, escalation and resolution history.
- Staff management
- Staff records, duty rosters and beat allocation.
- Reporting and dashboards
- Management reporting generated from the operational record.
- Analytics dashboard integration
- Consolidated analytics on top of the operational data, for officer-level reporting.
What the reporting layer looks like
Consolidated dashboards drawn from the operational record — patrol activity, coverage, incidents and veterinary caseload in one place, rather than compiled by hand at period end.
Real dashboards are not published here. Patrol coverage and animal location data are operationally sensitive, and access in the deployed system is scoped by role.
Before and after
The change is less about any single module than about where the record now lives — and who can see it.
Before
- Patrol and incident records kept in paper registers
- Operational data spread across spreadsheets
- Records held per function, not viewable together
- Reporting compiled manually after the fact
- Poor visibility across the park
After
- Patrols and incidents recorded in the field on mobile
- One shared record set behind portal, API and app
- Analytics dashboards integrated for officer reporting
- Reporting generated from live operational data
- Clear, current visibility through the dashboards
Scheme analysis and policy planning toolkit
Alongside park operations, the engagement covered a toolkit for scheme analysis and policy planning — supporting the design, development and monitoring of departmental schemes. This is public-sector programme management rather than zoo software, and it reflects the wider administrative context a state forest department works within.
- Scheme design
- Scheme development
- Scheme monitoring
Request a Zoo Systems Assessment
A scoped review of how your park records animals, patrols, veterinary care and incidents today — and a written roadmap of the modules worth building, in what order. No obligation to engage us afterwards.
Typically a 30-minute session plus a written follow-up within a week.