Multi-party approvals
A Netherlands-based microfinance management initiative runs its cooperative onboarding and project approval traffic on Tickiti. The scheme connects a network of local cooperatives with a central principal organisation, and every piece of documentation, every project proposal and every formal sign-off between them moves as a Tickiti ticket. This case study describes how a real microfinance management platform uses Tickiti interventions to run a structured, auditable, ticket-based approval workflow — in plain operational terms, without touching code.
The organisations involved
Two kinds of organisation work side by side in the scheme, and they are deliberately kept separate:
- Cooperatives (the “coops”) — member-owned local groups, often in different towns. A cooperative holds the relationships on the ground: it knows its members, originates community development projects, and gathers the paperwork. It is the party that provides documentation and proposes projects.
- The principal — the central body that governs the scheme. It vets each cooperative before it can operate, accepts or returns the projects cooperatives put forward, and is accountable for compliance and oversight. It is the party that reviews and accepts.
Approved projects are then opened to lenders for funding, but the day-to-day collaboration that this case study is about is the steady stream of documents, questions, corrections and formal decisions flowing between the cooperatives and the principal. That is where cooperative loan origination either runs smoothly or gets stuck — and it is exactly the work Tickiti coordinates.
Why the work runs on tickets
Because the principal’s reviewers work from queues, incoming submissions are sorted, assigned and prioritised the same way a busy support desk handles tickets. Work does not fall through the cracks, and the principal can see at a glance how much is waiting, how old it is, and who is handling it.
Every meaningful exchange between a cooperative and the principal is a decision that needs a record: who submitted what, who reviewed it, what was changed, and when it was signed off. Tickiti gives each of these its own ticket — a single durable thread that holds the conversation, the supporting documents and the final decision in one place. For a regulated microfinance scheme, that thread is the compliance audit trail: nothing about an onboarding or a project approval lives in someone’s inbox or on a shared drive.
Interventions: structured approval, not just messages
The piece that turns Tickiti from a messaging channel into an approval engine is the intervention. An intervention is a ticket that carries structured information and a built-in decision. Instead of reading a free-text message and hunting through attachments, the principal’s reviewer opens the ticket and sees a panel of the actual figures and details — the proposed amounts, the registration data, the bank details — alongside controls to confirm, adjust, accept or return.
When the reviewer accepts, the outcome is handed straight back to the microfinance management platform, which advances the cooperative or the project to its next state. There is no rekeying, no “please update the system” email, and no risk of the platform and the paperwork drifting apart. This is human-in-the-loop approval: a person makes the judgement, but the structured result is captured and applied automatically.
An intervention is, in plain terms, the principal’s back office asking a person to make one clear decision on a structured form — and having that decision flow back into the lending platform the moment it is made.
The two collaborations below are both built on interventions. The mechanics are the same; only the form and the outcome differ. (For the technical contract behind interventions, see the Interventions guide and Interventions quick start.)
Cooperative onboarding — providing documentation
A new cooperative cannot operate in the scheme until the principal has vetted it. To apply, the cooperative submits its founding documentation — registration papers, the identities of its officers, and its bank mandate. That submission raises an onboarding intervention in the principal’s onboarding queue.
The reviewer opens one ticket and sees everything needed to make the call: a structured panel listing the cooperative’s legal name, registration number, officers and bank details, with the uploaded documents attached to the same ticket for verification. The reviewer then does one of two things:
- Accept — the cooperative is activated on the platform and can begin proposing projects. The acceptance is recorded on the ticket.
- Return for correction — the reviewer notes exactly what is wrong (a missing signature, an expired document, a mismatched name) and the ticket goes back to the cooperative. The cooperative sees precisely what to fix and resubmits on the same ticket.
The document review and approval round-trips on one thread until the cooperative is accepted, so the full onboarding history — every version of every document and every reviewer note — stays together as a single record.
Project proposals — acceptance at the principal
Once a cooperative is active, it proposes projects for funding. A proposal carries the project’s scope, its financial schedule and repayment plan, and supporting documentation. Submitting it raises a project-proposal intervention: a ticket lands in the principal’s review queue with a structured panel of the proposed figures and the documents attached.
The reviewer assesses the proposal in one place. Where the scheme’s rules allow it, they can adjust a figure in the panel — for example capping a requested amount — before confirming. Then they either accept the project, which opens it for lending, or return it to the cooperative for revision with notes. On acceptance, the decision flows back to the platform automatically and a confirmation is posted to the ticket, closing the loop.
The interventions at a glance
| Intervention | Raised when | The principal decides | On acceptance |
|---|---|---|---|
| Cooperative onboarding | A cooperative submits its registration, officer and bank documentation | Are the documents and details in order? | The cooperative is activated and can propose projects |
| Project proposal | An active cooperative proposes a project with its scope, financials and documents | Accept the project as proposed (or adjusted)? | The project opens for lending |
What management gets from running it this way
Putting cooperative onboarding and project approval on Tickiti interventions gives the principal a back-office workflow that is consistent, visible and defensible:
- One audit trail per decision. Every onboarding and every project approval is a single ticket holding the documents, the discussion and the sign-off — ready for an auditor or regulator without reconstruction.
- Nothing slips. Submissions land in review queues that are sorted, assigned, prioritised and escalated, so a waiting cooperative is never forgotten.
- A consistent process for every cooperative. The same structured panel and the same accept-or-return choice apply across the whole network, so approvals are even-handed and easy to train new reviewers on.
- The system and the paperwork stay in step. Because an accepted intervention updates the lending platform automatically, the records and the live state never diverge.
- Documentation lives with the decision. The documents a cooperative provides are attached to the ticket where the decision is made, not filed separately.
- Clear visibility for the principal. Queue and reporting views show how much onboarding and project work is in flight, how long it is taking, and where the bottlenecks are.
Where to go next
- Interventions guide — how interventions work end to end.
- Interventions quick start — stand up your first intervention.
- Interventions technical reference — the full field and callback contract.