Every institution we speak to has an ERP.
Sometimes it is a large enterprise system. Sometimes it is something built in-house over the years. Sometimes it is a collection of modules stitched together with a shared login. But it exists. The institution invested in it, trained staff on it, and relies on it for the things that keep the institution running day to day.
And yet, when it is time to run a conference, a fellowship, a competition, or a scholarship cycle — the ERP disappears from the conversation entirely.
The coordinator opens a new Google Form. The submissions go into a spreadsheet. The reviewer assignments go into email. The payment confirmations go into someone's inbox. The whole program lives in a collection of tools that have nothing to do with each other and nothing to do with the ERP that was supposed to be the institution's operational backbone.
This is not a failure of the coordinator. It is a failure of category clarity. The ERP was never built to do this. And understanding why is the key to understanding what institutions actually need.
What an ERP Is Actually Built For
An ERP — Enterprise Resource Planning system — is built to manage what an institution is.
Students enrolled. Faculty contracted. Fees collected. Timetables scheduled. Payroll processed. Library inventory tracked. Hostel rooms allocated. Examination results recorded.
These are static or slow-moving records. A student's enrollment status. A faculty member's designation. A fee payment. They change infrequently, they follow predictable workflows, and they need to be accurate and permanent.
ERP systems are excellent at this. They are built for it. The data model, the workflows, the reporting — all of it is designed around the idea that the institution has defined entities (students, staff, courses, fees) and needs to keep accurate records of them over time.
That is a completely different problem from running a conference.
What a Program Actually Requires
A conference, a hackathon, a fellowship, a grant cycle, a scholarship round — these are not records. They are events. Time-bound, process-driven, people-intensive events with a beginning, a middle, and an end.
They require:
An open call that goes out to an audience the institution may not even know yet — external researchers, students from other institutions, industry professionals.
A submission intake that handles different file types, different program tracks, different eligibility criteria, and different payment structures.
A review workflow that assigns submissions to evaluators, tracks completion, manages conflicts of interest, and consolidates scores into decisions.
Communications that go to the right people at the right time — submission confirmations, reviewer reminders, decision notifications, schedule logistics, feedback letters.
A close process that documents everything — who submitted, who reviewed, what was decided, what was paid, what was communicated — in a format that can be retrieved and verified later.
None of this maps to an ERP's data model. An ERP does not have a concept of "an external researcher submitting a paper for peer review." It does not have a workflow for "assign this submission to three reviewers, collect their scores, and notify the author of the outcome." These are not ERP problems. They are program management problems.
And program management problems need a different kind of infrastructure.
The Cost of the Gap
When institutions try to run programs without dedicated infrastructure, they fill the gap with people.
Someone manages the submissions spreadsheet. Someone else handles the payment confirmations. A third person chases reviewers. A fourth compiles the evaluation scores. Someone senior makes the final decisions and communicates them. Someone else handles the logistics emails.
The work gets done. The conference happens. The fellowship cohort is selected. The competition results are announced.
But the cost is invisible because it is paid in coordinator hours, not in software invoices.
120 hours per program is a conservative estimate based on what we have seen institutions recover when they move to a dedicated platform. Fifteen working days. Across a team of people who had other work to do.
Multiply that across every program the institution runs in a year — conferences, competitions, fellowships, internal grants, student awards — and the hidden cost of the infrastructure gap becomes very large very quickly.
The ERP does not show this cost. The spreadsheets do not show this cost. It lives in the exhausted coordinator who stayed late again and the program that never happened because it felt like too much work to organise.
Why "We'll Build It Into the ERP" Doesn't Work Either
Some institutions, particularly larger universities with in-house IT teams, respond to this gap by building custom modules inside their existing ERP or student management system.
This solves the immediate problem and creates three others.
First, it takes time — typically months of development, testing, and rollout — during which programs continue running on spreadsheets.
Second, it requires ongoing maintenance. Every new program type, every change in workflow, every new requirement from a funding body or accreditation authority means a development ticket and a wait.
Third, and most importantly, it locks the institution into a static solution for a dynamic problem. Programs evolve. Evaluation criteria change. New program types emerge. A custom ERP module built for the conference workflow of 2023 may not handle the fellowship workflow of 2026 without significant rework.
A dedicated program management platform is built to evolve with the programs. New workflows, new program types, new compliance requirements — these are product updates, not development projects.
Two Systems, Two Jobs
The framing that resolves this is simple.
Your ERP manages what your institution is. JustPitch manages what your institution does.
These are complementary, not competing. The ERP holds the permanent record of enrolled students, contracted faculty, and collected fees. JustPitch holds the operational record of every program the institution runs — who applied, who reviewed, what was decided, what was paid, what was communicated.
Both need to exist. Neither replaces the other.
What JustPitch replaces is the spreadsheet, the shared inbox, the WhatsApp group, and the six-person coordination team that is currently doing the job that software should be doing.
What This Looks Like in Practice
Bharath College of Science and Management in Thanjavur ran their international conference BICET on JustPitch. Submissions came in through a single intake pipeline. Payments were tracked in the same system. Reviewer assignments were made inside the platform. Feedback and logistics communications went out through the same workflow that received the submissions.
The coordinator team was two people.
Before JustPitch, running the same conference required six to ten people and approximately 120 hours of coordination time. The ERP was not involved in any of that work, because it was never the right tool for it.
The right tool is infrastructure built specifically for the program lifecycle — from open call to final report, in one place, with a complete audit trail that builds itself as the program runs.
The Question Worth Asking
If your institution is planning a conference, a fellowship, a competition, or a scholarship round in the next six months, it is worth asking one question before the planning meeting ends:
Where is this program going to live?
If the answer is "we'll set up a Google Form and manage it from there" — that is a coordinator team being asked to be the infrastructure again.
There is a better answer. And it does not require replacing your ERP.
JustPitch is live with institutions across India and expanding internationally. If your institution is planning a program and wants to see what dedicated infrastructure looks like, request a demo at justpitch.in.