By industry
AI agents and member self-service for institutions and membership bodies
Associations, institutes, schools, clubs and NGOs run on a small office and a very large membership. Almost everything a member wants — a certificate, a renewal, a receipt, a form, an answer about eligibility — is something the office already holds and has to be asked for. We build the layer that lets the member get it themselves, and lets the registrar keep the final say where it matters.
Two weeks to a written build plan · no obligation to build with us
- Members served by a platform we built
- 10,000+Members served by a platform we built
- To live, including record migration
- 4 monthsTo live, including record migration
- Engagements with one body over three years
- 9Engagements with one body over three years
- Status changes still stop for a person
- Registrar signsStatus changes still stop for a person
Where the time goes
If two of these are true, there is something here
Written the way the people doing the work describe it, not the way a process document does.
The office inbox is the product
Members email to ask what grade they are on, whether their dues are paid, when the certificate expires and how to register for the AGM. Every one of those answers already exists in a system — it just cannot be reached without a member of staff.
Renewal season is three weeks of chasing
Somebody builds a list, sends the reminders, takes the payments, matches them back to member records by hand, and then reconciles what the bank says with what the spreadsheet says.
Records live in more than one place
The old database, the newer portal, the spreadsheet a past officer kept, and paper. Nobody is confident which one is right, so the safe answer to any member question is "let me check".
Chapters and committees do their own thing
Regional chapters run their own sites, lists and events. Head office finds out what happened afterwards, and the central member record is always a little behind.
What we connect to
The systems you are already running
Membership bodies rarely run one clean system. They run one system of record, one payment route, one mailing tool and a decade of exports. We work with all four.
- Membership and records
- Wild Apricot
- Salesforce NPSP
- Blackbaud
- Glue Up
- Custom Django / Laravel portals
- Legacy MySQL exports
- Learning, events and meetings
- Moodle
- Canvas
- Eventbrite
- Zoom
- Microsoft 365
- Google Workspace
- Payments and communication
- Stripe
- PayPal
- Local bank gateways
- bKash
- Mailchimp
- WhatsApp Business
What we build here
Five things worth building for institutions & membership
Each one names the systems it touches, because an integration that is not named is an integration nobody has thought about yet.
- 01
A member assistant that reads the record
Membership status, dues history, certificate validity, eligibility for a grade or an event — answered from your system of record, only after the member has been identified. It never invents a rule; when the answer is not in the record it says so and hands over.
- Touches
- Member database · payment gateway · portal login
- What changes
- The office inbox stops being the front desk for questions the system can answer.
- 02
Renewals that chase themselves
Reminders on your schedule and in your wording, a payment link tied to the member record, automatic matching of the payment back to the member, and a daily list of the ones that did not reconcile.
- Touches
- Member database · Stripe / bank gateway · email and WhatsApp
- What changes
- Renewal season becomes a short exceptions list instead of three weeks of chasing.
- 03
Registration and event operations
Event registration checked against eligibility and dues, seats and waitlists tracked, joining details sent, attendance written back to the member record so CPD or attendance credit is not a separate spreadsheet.
- Touches
- Events tool · member database · Zoom / venue lists
- What changes
- Attendance and eligibility stop being reconciled by hand after every event.
- 04
Documents and certificates on demand
Certificates, letters of good standing, receipts and membership confirmations generated from the live record with your template and signature rules, and released only to the member they belong to.
- Touches
- Member database · document templates · portal
- What changes
- Requests that took a staff day a week take a click.
- 05
One member record, including the chapters
Chapter and committee activity written back into the central record — joins, transfers, event attendance, local payments — with a reconciliation report where the chapter list and head office disagree.
- Touches
- Chapter sites · central database · reporting
- What changes
- Head office can answer a question about a regional member without phoning the region.
How it is put together
How a member question gets answered without a staff member
Identification first, record second, rule third, answer last. Reversing any of those is how a portal ends up telling the wrong person something it should not have.
- 01
Identify
The member is authenticated through your portal before anything is read. An unauthenticated question gets a generic answer and an invitation to log in — never a record.
- 02
Retrieve
The answer is pulled from the system of record, not from a model’s memory of your handbook. Every answer carries the field it came from, so a wrong answer is traceable to a wrong record.
- 03
Apply the rules
Grades, eligibility, dues policy and grace periods are code, versioned with a date. When a rule changes at the AGM, the change is a commit, and last year’s answers can still be explained.
- 04
Act or hold
Reading a record is unattended. Changing one — status, grade, waiver, refund — goes to the registrar with the proposed change and the rule that triggered it.
- 05
Log it
Who asked, what was disclosed, what changed and who approved. Membership bodies get audited by their own councils, and this is the record that answers them.
Your data
What we will and will not do with it
Stated plainly, and without claiming a certification we do not hold. If a requirement here is harder than what is written, say so on the call and we will tell you whether it is buildable.
Member data is not disclosed before identification
Nothing personal is returned to an unauthenticated session. That sounds obvious and it is the single most common failure in member-facing chat, because the convenient design is to answer first and check later.
Your records stay yours, and stay put
The access layer reads and writes your database; it does not copy your membership into a vendor system. If your constitution or funder requires data to stay in a jurisdiction, we run the model there or use an open-weights model on your own infrastructure.
Status changes are never automated to start with
Suspension, reinstatement, grade changes and fee waivers affect a person’s standing in a profession. Those stay with the registrar until you have watched the system propose them correctly for long enough to decide otherwise.
Proof
We have run a body this size before, migration included
IAB is a membership body whose operations ran through the office inbox. We built the portal that let members serve themselves — registration, renewals, chapter sites — and migrated every existing record into it, live in four months. The nine engagements since are the part that matters: it stayed in production and kept being extended.
- Members served
- 10,000+Members served
- To live, including migration
- 4 monthsTo live, including migration
- Engagements over three years
- 9Engagements over three years
Technology
What this gets built with
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Platform
- Django
- React
- Next.js
- PostgreSQL
- Celery
- Agents and retrieval
- LangGraph
- pgvector
- Structured output
- Record-grounded answers
- Identity and payments
- SSO / OAuth
- Portal auth
- Stripe
- Bank gateways
- Role-based access
- Operations
- Audit log
- Migration tooling
- Reconciliation reports
- Docker
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 1–2
Sit with the work
We watch the process as it is actually done, not as the process document says. The output is a map of every step, which system it touches and how long it takes.
DeliverableProcess map and a shortlist of what is worth automating - 02Week 2–3
Design the access layer
Which systems get read, which get written to, what scope each credential carries, and which decisions stop for a person. Agreed in writing before anything is built.
DeliverableArchitecture and permission model - 03Week 3–8
Build against your real data
Built in your sandbox against real records, not a demo dataset. The write path goes through a review queue from the first day, so nothing lands in a live system unseen.
DeliverableRunning system in staging, with the review queue - 04Week 8–10
Run it beside the humans
It runs in parallel with the people doing the job. We compare the two outputs, fix what differs, and only then start letting the routine path through unattended.
DeliverableAgreement rate report and a go-live threshold - 05Ongoing
Hand over and watch
Source code in your repository, deployment in your accounts, cost and failure dashboards you can read without us. Support if you want it, not because you are locked in.
DeliverableRepository, runbook and monitoring
Why Devs Core
Three reasons that are checkable
We run two of our own products
Cadenza and Budge are ours. What an agent costs per run, where it fails and which decisions need a person came from operating them, not from a vendor deck.
The write path is reviewed by default
Anything that changes a record in a system of record goes through a queue a person can see. You choose what graduates to unattended, and when.
You own the code
Source in your repository, infrastructure in your accounts, model keys in your name. There is no runtime of ours you have to keep paying for.
Questions
Institutions & Membership — the questions we get asked
Can a chatbot see member data without a security problem?
Only if it is not really a chatbot. What we build authenticates the member through your portal first and then reads their record through a scoped API — the same permissions a logged-in member already has. It has no ability to read a record belonging to someone else, because the credential it uses cannot.
Our records are a mess across three systems. Do we have to fix that first?
No, and waiting until the data is clean is how these projects never start. We have migrated a full membership before. The usual order is: agree which system is authoritative per field, migrate, then build on top of the result.
Will this replace our membership platform?
It does not have to. If your platform holds the records well and only the member experience is poor, we build on top of it. If the platform is the problem, we have built the replacement before — that is the IAB engagement.
Can it take payments and mark a member as renewed?
It can take the payment through your existing gateway and match it to the member. Whether marking the record as renewed is unattended is your decision: most bodies start with a proposed batch the office confirms, then release the clean cases once the matching has proved itself.
What about our regional chapters running their own sites?
That is normal and it is usually where the reconciliation pain is. We either connect the chapter sites back to the central record or replace them with chapter sub-sites on the same platform. Both have worked; which one is right depends on how much autonomy the chapters need to keep.
We are an NGO with a tight budget. Is this affordable?
The two-week AI Readiness Audit is the honest first step, and it is fixed price. It ends in a written plan you own, including the option of doing nothing. Most institutions get more out of one well-chosen flow — usually renewals or member questions — than out of a large programme.
How do we stop it giving a member the wrong answer about eligibility?
Eligibility is not left to the model. It is written as rules against your constitution and by-laws, versioned, and testable. The model reads the question and finds the record; the rules decide the answer.
Related
What institutions & membership buys most often
- Read more
AI Agent Development
Agents that take real actions in your systems — reading live data, drafting work, and writing back only what a person has approved.
From $6,500 - Read more
Custom Software Development
The operational system underneath — the one the packaged software did not cover. React and Django, built to be handed over.
From $14,000 - Read more
Web Development
Fast, accessible, search-ready sites and web applications — the kind that load in under a second and rank because of it.
From $3,500 - Read more
AI Integration Services
The access layer between the software you already run and any AI model — so an agent can reach your ERP, CRM or helpdesk without being handed the keys.
From $8,000
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com