Why feature-first buying fails
Two systems may both claim admissions, fee management, attendance, and reporting. Those labels reveal little about the school's real work. Can an application be incomplete? Who approves a fee adjustment? How is an unmatched payment investigated? Can a class change preserve historical records? Who can correct a published result?
Without a process map, demonstrations follow the vendor's ideal path. Duplicate work, ownership gaps, approval delays, and exceptions stay hidden until implementation.
Map the current state without defending it
- Choose one event: for example, “a parent pays via a digital channel.”
- Name the start and end: payment is received; learner balance and evidence are correct.
- List actors and systems: parent, bank/payment platform, finance user, student record, accounting tool, communication channel.
- Record each handoff: data, owner, timing, and method.
- Add decisions and exceptions: missing reference, partial payment, duplicate transaction, reversal, wrong learner.
- Mark evidence and reports: receipt, audit entry, reconciliation, outstanding-balance report.
Worked example: an unmatched fee payment
| Step | Current question | Risk exposed |
|---|---|---|
| Receive | Which identifier arrives with the transaction? | Reference may not match a learner |
| Match | Is matching automatic, suggested, or manual? | Wrong account allocation |
| Exception | Where does an unmatched item wait and who owns it? | Payment disappears into a spreadsheet |
| Approve | Who may correct or reallocate, with what evidence? | No segregation or audit trail |
| Communicate | When is a receipt or correction notice sent? | Parent and ledger show different states |
| Report | How is reconciliation completed and reviewed? | Delayed or unreliable balances |
This map does not prescribe a product. It creates testable requirements for any product or payment-system integration.
Design the future state
Remove duplicate entry, clarify ownership, simplify approvals, and decide where each authoritative record lives. Do not automate every current step; some steps exist only because systems are disconnected. Preserve necessary human review where judgement, safeguarding, sensitive communication, or financial control requires it.
- One accountable owner is named for the outcome.
- Each data item has an authoritative source.
- Approval paths match risk rather than habit.
- Exceptions have a queue, owner, deadline, and evidence.
- Reports are outputs of the process, not separate reconstruction.
- Access follows role and changes when responsibility changes.
Turn the map into selection criteria
For every priority workflow, write: “The system must allow [role] to [action] using [data], with [control/evidence], including [exception], so that [outcome/report].” Ask vendors to demonstrate that exact scenario. Score fit, configuration, workarounds, integration, and operational ownership separately.
Connect this work to the school management system buyer's guide and core school process map. Webivon uses process mapping as part of implementation planning, whether the final answer is configured software, custom development, integration, or a hybrid.