From Paperwork to Platform: How Aarna Education Modernised Its Admissions Operations End-to-End

## Overview Aarna Education has been quietly building something remarkable. Founded in 2008 as a single campus in Hubballi, the group had grown to 17 schools spanning nine districts by mid-2024, collectively serving more than 12,400 students across pre-primary, primary, secondary, and senior secondary streams. Despite its academic reputation and steady enrolment growth, the institution's back-office technology stack had not kept pace. Admissions paperwork was being processed largely by hand. Fees were tracked across three disconnected spreadsheets. Parent communication was routed through WhatsApp, email, and an increasingly unmaintained WordPress noticeboard — all operating in parallel with no single source of truth. This case study chronicles the discovery, design, build, and rollout phases of a six-month transformation programme delivered by Webskyne Studio between January and June 2025. We focus on the admissions workflow as the primary deliverable, with supporting modules for fee reconciliation, transport management, and parent portals. ---  --- ## Challenge In December 2024, the admissions team at Aarna's headquarters described a situation that most growing education groups know only too well: the peak admissions window (November through March) was an annual exercise in fatigue. Parent inquiries arrived via multiple phone numbers and email aliases. Enquiry forms were printed for campus visits and later re-entered manually into a LocalDB-backed web app that had not seen a security patch in three years. Fee receipts were generated as PDFs in Google Docs and emailed individually. Transport route allocations were drawn on whiteboards and updated by phone call. None of this would have been tolerable at smaller scale. At 17 campuses and 12,400 students, the strain was beginning to show in three critical dimensions: 1. **Data integrity.** Multiple versions of the same student record existed in different files. The finance team routinely spent the first two days of every month reconciling payment records across spreadsheets and bank statements — a process that had grown to consume approximately 40 person-hours per campus. 2. **Parent experience.** Parents calling to check admission status were frequently put on hold while staff searched for files. Post-admission, fee reminders, transport updates, and circulars arrived through inconsistent channels, creating confusion and eroding trust. Net Promoter Score (NPS) surveys conducted in February 2024 produced a parent NPS of +18 — respectable for a mid-sized group but well below the +50 benchmark set by comparable organisations. 3. **Administrative overhead.** The annual admissions cycle consumed approximately 120 hours of senior administrator time per campus in manual data entry alone — a figure that grew to over 150 hours when follow-up calls, re-verifications, and document sorting were included. Across 17 campuses, this represented more than 2,700 hours of unproductive work during a four-month window. ---  --- ## Goals Before any development began, we conducted a structured goal-setting workshop with the executive team, the admissions director, and the IT lead. The outcomes crystallised into four primary objectives, each accompanied by measurable acceptance criteria: **Goal 1: Centralise admission data in a single source of truth.** The target was a unified database with role-based access, eliminating the need for spreadsheet reconciliation. Success was defined as zero reconciliation hours for new batches within three months of go-live. **Goal 2: Reduce manual administrative effort by at least 60 %.** Drawing on industry benchmarks for education ERP implementations, we set a target of 60-plus-percent reduction in documented manual hours during the first operating cycle. **Goal 3: Improve parent satisfaction to an NPS of +50 or higher.** This was the most ambitious target. It required real-time access to admission status, fee details, and transport information through a self-service parent portal. **Goal 4: Achieve a go-live ahead of the November 2025 admissions window.** Timeline compression was important — building in-product during the busy season would have caused operational stress without providing the soft-launch buffer needed to resolve edge cases. --- ## Approach Our methodology followed a four-phase iterative model: Discover, Design, Validate, and Deploy. Each phase produced artefacts reviewed by the client before the next was initiated, ensuring continuous alignment and minimising the risk of costly rework. ### Phase 1 — Discover (Weeks 1–4) We embedded a two-person team at the Aarna headquarters in Bengaluru and conducted 14 structured interviews across operations, finance, admissions, transport, and parent relations. We also audited every existing tool in the stack: the LocalDB admissions web app, three Google Sheets fee workbooks, a shared WhatsApp Business number used for parent communication, and a Joomla noticeboard that received approximately 120 unique visits per month. The interview transcripts and tool audits were synthesised into a 38-page discovery report that included a functional requirement matrix, an org-chart-based RACI map, and a preliminary data model. One finding stood out immediately: the admissions form PDFs — which were generated using a third-party SaaS tool and stored in a shared but unorganised Google Drive folder — contained no structured data that could be ingested programmatically. This meant that any migration would require a hybrid approach combining new submissions through a structured form and a one-time backfill of existing records. We documented this as a key risk and proposed a parallel-run validation strategy. ### Phase 2 — Design (Weeks 5–8) Working within a design system built on Tailwind CSS and Headless UI, our UX team produced a full set of high-fidelity wireframes covering eight primary user journeys: - Admissions inquiry capture and routing - Enquiry-to-admission conversion with document upload - Student profile management and dashboard - Fee configurator and invoice generation - Payment reconciliation and automated receipting - Transport route assignment and real-time GPS polling - Parent portal login and self-service view - Admin dashboard with campus-level filtering A crucial design decision was the introduction of role-based dashboards. Instead of one shared interface with differing permissions based on page-level checks, each role saw a curated landing view that surfaced only the information and actions most relevant to their job. For the campus admissions officer, this meant seeing pending follow-ups, incomplete documents, and today's fee target rather than a full system navigation tree. ---  --- ### Phase 3 — Build (Weeks 9–16) The engineering stack was chosen deliberately to minimise operational overhead while maximising grid flexibility. The backend was built on NestJS with a PostgreSQL primary database, providing strong typing, structured dependency injection, and excellent migration tooling. Auth0 was used for identity management, supporting both institutional SSO and parent password-based access without the complexity of building and maintaining a custom OAuth implementation. Stripe was integrated for fee payments, chosen for its transparent developer documentation and the availability of India-specific payment methods including UPI, net banking, and card-based settlement. The frontend layer was built with Next.js 14 using the App Router and Server Components, enabling partial rendering and type-safe server actions for operations that needed immediate server-side effects. For transport tracking, we integrated with a third-party real-time geolocation API and implemented a WebSocket-based push notification layer using Socket.IO so that parents could receive approximate ETA updates without polling. One implementation surprise emerged during Week 12. The fee configurator module, which we had architected as a simple key-value schema in the database, needed to account for sibling discounts, transport fee overrides, yearly international admissions, and optional co-curricular fee add-ons — a total of 27 distinct fee-relevant dimensions. We refactored the schema in a single three-day sprint, added a pricing rule engine using a lightweight decision-table pattern, and tested the resulting invoice generation logic against 51 historical fee records from the prior cycle. The refactored module produced correct invoices 100% of the time and handled edge-case combinations that had previously required manual overrides. ### Phase 4 — Pilot and Deploy (Weeks 17–24) The rollout strategy was carefully staged. We chose three campuses from different geographic regions — one urban (Bengaluru), one semi-urban (Hubballi), and one rural (Kolhapur) — to represent the full spectrum of on-the-ground conditions. Each pilot campus ran in parallel with its existing processes for four weeks, providing a live comparison basis. Issue triage was conducted daily at 09:30 IST, with a central Slack channel used to log P1 through P3 severities. The first pilot week produced 23 bugs across the three campuses, primarily data-validation mismatches and document-upload permission errors. All were resolved within 48 hours. By the end of Week 4 of the pilot, the only open issues were two feature requests — one for additional report columns in the admin dashboard, and one for idempotent retry logic on Stripe webhook failures. Both were closed before the full rollout began. The full deployment across all 17 campuses was executed on a Friday evening in June 2025, chosen to minimise impact on the ongoing academic cycle. On-call engineers were available from Friday 20:00 IST through Sunday 18:00 IST, and we staged data migration in batches of 100 student records to avoid DB lock contention. The migration completed in 4 hours and 17 minutes, approximately 13 minutes ahead of the projected run-window estimate. --- ## Results Thirty days after full deployment, the operational picture had changed significantly. The admissions team across all 17 campuses reported zero spreadsheet-based reconciliation for the current admission cycle — a first in the group's history. The centralized PostgreSQL database had become the single source of truth for all student records, with 98.7% of migrated records passing the automated data-quality audit on the first pass. The remaining 1.3% (approximately 160 records) were manually reviewed and corrected within 72 hours of go-live. Parent feedback collected through the portal's in-app survey mechanism showed an average satisfaction rating of 4.6 out of 5 across 2,847 responses, up from a baseline of 3.1 recorded in the pre-deployment survey of February 2025. The parent NPS, the primary KPI for communication quality, reached +54 at the 30-day mark — exceeding the +50 target ahead of the September 2025 quarter-end. Fee reconciliation time dropped to an average of 2.5 hours per month per campus from a documented baseline of 37.5 hours per month per campus — a reduction of 93%. Even accounting for the initial parallel-run month, where some reconciliation dual-track was maintained as a safety measure, the net reduction remained above 85%. Transport route assignments, previously managed on whiteboards, were now updated in real time as GPS events processed through the API. Parent satisfaction scores for transport communication specifically rose from 3.4 to 4.8, the largest single-kpi improvement in the initial 30-day window. --- ## Metrics The table below summarises the key metrics before and after deployment across the five primary dimensions of the programme. | Metric | Pre-Deployment (Baseline) | Post-Deployment (30-Day) | Change | |---|---|---|---| | Parent NPS | +18 | +54 | +36 | Fee reconciliation hours (per campus per month) | 37.5 hrs | 2.5 hrs | −35 hrs (−93 %) | Parent communication satisfaction | 3.1 / 5 | 4.6 / 5 | +1.5 pts | Manual admin hours per admissions cycle | ~155 hrs/campus | ~34 hrs/campus | −121 hrs (−78 %) | Data quality audit pass rate (first pass) | N/A | 98.7 % | N/A | Transport location update latency | Manual, variable | Real-time via WebSocket | Near-zero | Sponsored post-engagement rate on parent portal content | 3.2 % | Not measured (launched with sponsored content integration) | N/A | Total maintenance burden (spreadsheet tools in use) | 11 active tools | 0 (consolidated) | −11 These results were validated through a combination of automated database logging, in-portal satisfaction surveys, monthly staff engagement calls, and a post-deployment audit conducted by an external consultant engaged by Aarna Education. ---  --- ## Lessons Learned Three lessons from this engagement stand out as broadly transferable to other organisations navigating similar transformations. **1. Start with data quality before you start with features.** The discovery phase revealed that the most urgent need was not a new feature but a systematic understanding of existing data quality. A steep investment in data mapping and quality assessment before any code was written saved an estimated 200 engineer-hours in rework during the build phase — a number that would have been significantly higher had the schema work begun without that grounding. **2. Parallel-run pilots are worth the extra coordination overhead.** Running three geographically distinct pilot campuses in parallel with existing operations for four weeks before any full rollout decision felt risky at the time. The data it produced was invaluable: it surfaced edge-cases specific to rural connectivity conditions and to fee-collection patterns in urban campuses that a single pilot region would almost certainly have missed. The extra coordination overhead was roughly 30 hours of internal project management time across the pilot window; it saved an estimated 400-plus hours of unplanned rework. **3. Build for the people doing the work, not the org chart.** The dashboard-design strategy of role-based landing views rather than one shared interface was driven by one recurring observation: the campus admissions officer's job does not involve managing teachers, editing finance reports, or configuring transport routes. When the navigation surface reflects the priority tasks of the active day rather than the full tool surface, adoption resistance drops sharply — and user satisfaction climbs as a result. The post-deployment survey confirmed that 94% of admissions and finance staff rated the new dashboard as "supportive of their daily workflow," compared to 38% who had rated the old spreadsheet-based approach similarly. --- ## Conclusion The Aarna Education engagement illustrates a consistent pattern that we have observed across six similar transformations in the education sector: the back office is rarely a glamorous investment priority, but is often the single highest-return intervention available to a growing institution. Centralising admissions data alone delivered a measurable improvement in parent experience, freed hundreds of professional hours for more strategic work, and created a foundation on which Aarna is already building — roll-out of a co-curricular activities management module is scheduled for August 2025, and a parent mobile application is planned for the final quarter of the year. The platform we built is not a finished product. It is an operating surface that will continue to evolve as Aarna Education expands. That intentionality — building for the road ahead rather than just solving this year's crisis — is arguably the most important design decision made throughout the engagement. For teams facing similar scaling challenges, the through-line from this case study is simple: map the reality of how your institutional processes actually work, build for the users who will live in the system every day, and let the data — not the hype — guide what gets built first.