Software that follows the process, until the process is wrong
Take a school that runs fee collection through a combination of a bank challan portal and a ledger that the accounts clerk maintains in a spreadsheet. When a parent pays late, the clerk applies a flat Rs. 50 charge manually, sends a WhatsApp message to the class teacher, and the class teacher forwards it to the parent. This takes about four minutes per late payment. There are a few hundred late payments a month.
A typical off-the-shelf school ERP has a fee module. It handles late fees — but as a percentage of the outstanding amount, configured once, applied automatically. It has no concept of "class teacher sends a message." It has automated SMS, billed per message, sent from a generic sender ID.
The way we would build that fee module is to match the spreadsheet process: flat charge, manual trigger, message routed through the class teacher's WhatsApp Business number. The accounts clerk sees a button labelled "send late fee notice to class teacher." The class teacher sees a pre-filled message with the student's name and the amount. They review it, edit it if the parent has already called, and send it. Two screens, two people, one round-trip.
This is the shape of most of our ERP and CRM work. An organisation has a process that works — not elegant, not optimised, but working, in the sense that the people doing it know what to do and the people receiving it understand what's happening. The software should hold that process, not replace it with something that looks cleaner in a demo.
Where we push back is when the existing process costs more than it saves.
Now take attendance reconciliation at the same kind of school. The class teacher marks attendance on a paper sheet, submits it to the office clerk at the end of the day, and the clerk enters it into the system — the same system the class teacher can see on their phone. Ask why the teacher doesn't enter it directly. "They might make a mistake" is the usual answer.
This is where we push back. The clerk re-entry adds a full day of delay before attendance is visible to parents. It introduces its own transcription errors — expect to find a dozen mismatches a month between the paper sheet and the system in a school of any size. And the safeguard the school wants, a second pair of eyes, can be delivered by a daily exception report that flags changes made after 10 a.m. or edits that touched more than three records in one class.
So the build looks like this. The teacher enters attendance. The clerk gets an exception report at 11 a.m. and investigates anything that looks wrong. The paper sheet is gone.
The distinction we try to hold is: follow the process where it encodes real knowledge about how the work should flow. Push back where the process is really a workaround for a fear the software can address directly.
Another example, from manufacturing. Picture a purchase approval workflow where the plant manager has to sign off on every PO above Rs. 10,000, and a request to build that step into a custom ERP. Ask how often the plant manager actually rejects a PO. The honest answer is often: never, in years. Ask what happens instead. The price gets negotiated before the PO is raised — that's where the real approval happens, in a conversation between the purchase manager and the plant manager, before anything hits the system.
The approval step then becomes an optional flag on the PO. The purchase manager can route it to the plant manager for sign-off, but the default is to skip it. The audit log records who raised the PO and who paid the invoice. The safeguard the sign-off was supposed to provide is delivered by the purchase order itself, which the plant manager can see at any time.
The rule we keep is: if we can't explain why a step exists, we build it as configurable and off by default. If we can explain it — the class teacher's judgement about whether a parent already knows, the accounts clerk's understanding of which late fees get waived — we build it into the flow and don't make it optional.
Built this way, the late fee process stays the school's own. The class teacher still edits the message sometimes. The flat charge still applies. The software doesn't try to make it prettier than it is.