NGO CRM — One Person Record, and Every Document That Comes From It
Members, volunteers and interns in one system, with certificates, ID cards and 80G receipts generated from the record instead of a Word template.
Client
[CONFIRM: Sevadharam — written permission needed before publishing a named case study]
Industry
Non-profit / Social Sector
Timeline
[CONFIRM: build duration]
Services
Product Design, Custom CRM Development, Document Automation, Role-Based Access, Multi-tenant Architecture
The Challenge
The work is the easy part. Proving it is the part that breaks.
An NGO is judged twice. Once on the work it does, and once on the paper trail behind it — the receipt a donor needs at the end of the financial year, the certificate a volunteer was promised, the identity card a field worker carries, the list an auditor asks for.
The second one is almost always run out of a folder of templates.
The underlying pattern
The people list lives in a spreadsheet. Identity cards get made one at a time in a design tool. Certificates come out of a document template at the end of a programme, filled in by whoever has the file open. An 80G receipt is typed into a Word document and sent from somebody’s personal email account.
Each of those documents carries the organisation’s name. One of them carries a donor’s tax position. None of them leaves behind a record of who issued it, when, or to whom.
The failure is not dramatic. It shows up as small, repeated incidents: a donor asks for a duplicate receipt and nobody can find the original. A volunteer asks for a certificate from a programme two years ago. Somebody who left the organisation a year back still has edit access to the template folder. A name is spelled one way on the ID card and another way on the certificate, because they were made by two people from two copies of the list.
Why it gets worse rather than better
Administrative load in an NGO scales with the number of people it touches, and administrative capacity does not. The team that can handle it at forty members cannot handle it at four hundred — not because the work is harder, but because the same manual act is repeated four hundred times, and each repetition is another chance for a wrong name, a missing record, or a document nobody can reproduce.
So the documents get deferred. Deferred becomes batched. Batched becomes forgotten, and the organisation quietly stops being able to prove things it genuinely did.
What needed to be solved
One record per person, whether they are a member, a volunteer or an intern — not three separate lists.
Documents generated from that record, so the name on the certificate is the name in the system.
A log of every document issued and every mail sent, available without asking anyone.
Roles, so that issuing an 80G receipt is a different permission from adding a volunteer.
An activity trail that exists by default rather than being something somebody remembers to keep.
A system the next administrator can be handed without also being handed a folder of templates and a verbal explanation.
How we framed the brief
The brief was not “build a database of members”. It was: make the document an output of the record, and make the act of issuing it leave a trace. Everything else in the system follows from that one decision.
What We Did
We made the person record the source, and every document a product of it.
Our approach
The test we designed against: can the organisation answer “who issued this, to whom, and when” for any document it has ever produced — without asking a person?
Any design that failed that test was rebuilding the template folder with better styling.
01 — People, in one place, by type
Members, Volunteers and Interns are separate record types in one system rather than three spreadsheets, with Categories so an organisation can group people the way it actually works — by programme, by chapter, by role — instead of the way a generic tool assumes.
Keeping them as distinct types rather than one flat “contacts” list matters, because what each one is owed is different. An intern needs a completion certificate. A volunteer needs an identity card. A donor needs a receipt. One flat list forces that logic into somebody’s head; typed records put it in the system.
02 — Documents generated from the record
Certificates, identity cards and 80G receipts are produced from the person record, not from a template somebody fills in.
This is the whole project in one line. A template can be filled in wrongly. A generated document cannot disagree with the record it came from — and if the record is wrong, correcting it corrects every document issued from that point rather than one file on one laptop.
Salary slips work the same way for paid staff.
03 — An email log, because sending is also a record
Every document that leaves the organisation by mail is logged with its recipient and its time. “We sent it” stops being a claim and becomes a row.
For an organisation that has to answer to donors, funders and auditors, the sending is as material as the issuing. A receipt that was generated but never reached the donor is a problem that only shows up months later, usually at the worst time.
04 — Roles and permissions
Issuing a statutory receipt and adding a volunteer are different acts with different consequences, so they are different permissions. The system is built around a Super Admin role with the ability to define what everyone else can see and do.
The practical effect is that access can be removed when somebody leaves — a step that simply does not exist when the “system” is a shared folder.
05 — An activity trail that keeps itself
The dashboard carries a running record of what happened and who did it: sign-ins and sign-outs, certificates downloaded, identity cards generated, receipt settings changed.
Nobody has to remember to maintain this. That is the point — a log that depends on discipline is a log that is accurate until the first busy week.
06 — Built as a tenant, not as a one-off
The organisation sits in the system under its own NGO identifier, with its own plan usage, storage and subscription state. The second NGO on the platform is a new tenant rather than a new build.
That decision was made at the start rather than retrofitted, which is the difference between a product and a project that will have to be rewritten the first time somebody else wants it.
Delivered
Member, volunteer and intern records with categories
Certificate, identity card and 80G receipt generation
Salary slips for paid staff
Email log of everything sent
Users, roles and permissions
Activity trail and plan usage reporting
Multi-tenant architecture with per-organisation subscription
The Outcome
One record per person — and every document traceable back to it.
The organisation runs its people and its paperwork from one system, where the document is a product of the record rather than a file somebody made.
Documents stopped being handmade
Certificates, identity cards, 80G receipts and salary slips are generated rather than typed, which removes the two failure modes that cause the most trouble later: the wrong name, and the document nobody can reproduce.
The audit trail exists without anyone maintaining it
Who issued what, to whom, and when — plus a log of everything that was emailed out — is available as a matter of course rather than as a reconstruction exercise.
Access can be given and taken away
Roles and permissions mean the ability to issue a statutory receipt is something that can be granted deliberately and removed cleanly.
Built honestly, in phases
The system is live with its first organisation. Bulk member, volunteer and intern handling is explicitly flagged in the product as a later phase, and is shown that way inside the dashboard rather than hidden — the team can see what the system does today and what is still coming.
We would rather a client see an honest “coming in a later phase” than a feature that half works.
What this unlocked
The administrative work no longer grows in a straight line with the number of people the organisation touches, which is the constraint that was quietly limiting it.
Person types — members, volunteers and interns — unified into one record system rather than three separate lists.
Document types generated directly from the person record: certificates, identity cards, 80G receipts and salary slips.
[CONFIRM: a real outcome number — e.g. people records migrated, documents issued since go-live, or hours of admin removed per month. Do not publish an invented figure.]
