Loading
Casework

Case management, from referral to outcome

Casework has a shape that generic software rarely fits: a referral arrives from somewhere unpredictable, someone assesses it, a person owns it, things happen over weeks or months, and at the end a funder or a commissioner wants evidence of what changed. We build systems around that shape rather than asking your service to adopt someone else's.

Track cases from referral to outcome.

You are probably here because

  • Cases live across a shared mailbox, a spreadsheet and one person's memory.
  • Nobody can say how many open cases a worker is carrying without counting.
  • A quarterly funder report takes days of copying between spreadsheets.
  • Referrals arrive by e-mail and get logged when someone gets round to it.
  • Case notes are in Word documents in folders named after the client.
  • Two teams hold overlapping records about the same person and neither is authoritative.
  • Demonstrating an outcome means reconstructing it from memory and e-mail.

What is actually going wrong

The work is being done well. The problem is that the record of it is spread across systems that were never meant to hold it, so every question about the service in aggregate — how many, how long, what happened, what changed — has to be answered by hand.

That has two costs. The obvious one is time, most visibly at reporting deadlines. The less obvious and more damaging one is that nobody sees the service clearly enough to manage it. Caseloads drift, cases go quiet without anyone noticing, and the first sign that something has been sitting untouched for eleven weeks is usually a complaint.

Off-the-shelf case management exists and sometimes fits. Where it tends not to is the two ends: how a referral arrives, which is always specific to your partners, and what an outcome means, which is defined by your funders and changes when the funding does. A system you cannot change at those two points is one you will be working around within a year.

What we build

A case record with the stages your service actually uses, ownership and assignment, SLA timers against the deadlines you are held to, notes and documents attached to the case rather than to a folder, and outcome recording defined the way your funders define it.

Referrals come in through whichever channels you actually receive them on — a form on your site or a partner's, an inbox that is processed automatically and filed against the right record, or an API where a partner organisation can push them directly.

On top of that, the reporting layer is the part that repays the project fastest. The report builder joins the related tables for you, so the recurring funder and commissioner reports are built once by your own team and then scheduled to send themselves. Caseload dashboards per worker turn managing the service into looking at a screen.

How it goes together

  1. 01

    Model the case, not the software

    Cases, people, organisations, notes, documents and outcomes as linked datastores with your own fields and your own vocabulary. If your service says "referral" and "episode", the system says that too. This sounds cosmetic and is not — staff adoption is largely a question of whether the software speaks the language of the work.

    Built from
    Datastores40+ field typesQuery builder
  2. 02

    Take referrals from where they actually come

    A public or partner-facing form, an inbox that fetches and files inbound e-mail automatically including attachments, or an API endpoint for partners who can integrate. Most services need at least two of these, and the manual route never goes away entirely.

    Built from
    FormsInbox processingAPI engine
  3. 03

    Put the process and the clock on it

    Stages with assignment, so a case always has an owner, and scheduled tasks that watch the dates you are measured on — first contact, review due, case dormant — and escalate before rather than after the breach.

    Built from
    WorkflowsScheduled tasksSMS alerts
  4. 04

    Control who can see which cases

    Casework data is among the most sensitive a small organisation holds. Security groups scope visibility by team, service or geography; field-level permissions keep safeguarding notes away from people who do not need them; and per-column encryption protects the fields that would matter most in a breach.

    Built from
    Security groupsCustom permissionsEncryptionAuditing
  5. 05

    Make the funder report a button

    Build each recurring report once, with its filters and date ranges, then schedule it. The quarterly return stops being a week of work and becomes something that arrives in an inbox — including, where the funder will accept it, in theirs.

    Built from
    ReportsSummary reportsGraphsScheduled tasks

The platform features doing the work

Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.

FeatureWhat it doesWhy it matters here
Datastores & 40+ field typesYour own entities and fields, with linked dropdowns, dates, signatures, file uploads, geolocation and conditional fields.Outcome frameworks are specific and they change with the funding. Being able to add a field yourself is the difference between adapting and re-procuring.
Inbox processingInbound e-mail is fetched automatically and passed, with attachments, to data extraction or a custom function.Referrals arrive by e-mail whether or not your process says they should. This files them against the right case instead of leaving them in a shared mailbox.
Scheduled tasksAutomated tasks at any interval — built-in features or custom functions.Chasing reviews, flagging dormant cases and sending the reports that used to be assembled by hand.
Reports & summary reportsA builder that joins related tables automatically, with filters, date ranges, counts of distinct values and graph output.Funder reporting is the recurring cost casework services most consistently underestimate. This is where the project pays for itself.
AuditingFull change history with rollback, plus a chronological site-wide activity log.For a complaint, a serious case review or an inspection, "who knew what, and when" needs an answer that is not somebody's recollection.
EncryptionPer-column encryption, so the data stays unreadable even if the database itself is compromised.Applied to the specific fields whose exposure would cause real harm, rather than as a blanket claim.

What you end up with

  • Every case has an owner, a stage and a full history
  • Caseload dashboards per worker, and a dormant-case list nobody has to compile
  • Referrals captured from forms, e-mail and partner APIs
  • Outcome fields defined by your funders, changeable when the funding changes
  • Recurring reports generated and scheduled, not assembled
  • Field-level permissions and per-column encryption on sensitive notes

Whether this is for you

A good fit when

  • Charities, social enterprises, housing providers, local authority teams and health services running casework.
  • Services reporting to more than one funder, each wanting outcomes cut a different way.
  • Anywhere a case passes between people or teams and things fall down the gap.
  • Organisations where the sensitivity of the data means access control has to be demonstrable.

Probably not, if

  • A service small enough that a well-kept spreadsheet genuinely works and no funder is asking for more. Come back when that stops being true.
  • Organisations wanting a fundraising CRM. That is a different product category and there are good ones — this is about service delivery.
  • Anywhere the outcome framework is still being argued about. Settle what you are measuring first; building it early bakes in the wrong answer.

How a project like this runs

First

The case record, stages and one referral route, with real cases in it. Caseworkers using it in week three tells you more than any amount of specification.

Then

The remaining referral channels, the permission model in full, and the reporting layer — usually timed to land before a reporting deadline that matters.

Handover

Reports and fields are things your own team builds afterwards. For most casework services that is the capability that matters most, because the questions change every funding round.

Questions we get asked

How is this different from an off-the-shelf case management product?

Mainly at the two ends. How referrals arrive is specific to your partners, and what counts as an outcome is defined by your funders and changes when the funding does. Products fix both, so services work around them. Here they are configuration, and your own team can change them.

Can we produce the reports our funders ask for?

Yes, and building them is meant to be your job rather than ours. The report builder joins the underlying tables automatically, so a report is filters and date ranges rather than a query someone has to write. They can then be scheduled to send themselves.

How is sensitive case data protected?

Layered. Security groups scope which cases a person can reach at all, field-level permissions control which columns they see within those, and per-column encryption protects specific fields at rest. Everything is audited, including who viewed what.

We report to several funders who all want different figures. Is that a problem?

No, and it is the normal case. Outcomes are recorded once against the case; each funder's view is a different report over the same data, not a different set of fields to maintain.

Is it hosted in the UK?

Yes, by default. The platform is UK-built and already used by NHS trusts and public-sector organisations, so UK data residency and the assurance paperwork are routine rather than exceptional.

Sound like your week?

Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.