Legislative Constituent Casework Software: When One Unsigned Privacy Release Stops the Whole Case

Why casework software is the difference between an office that helps and one that apologizes

A veteran walks into your district office on a Tuesday. His disability claim has been pending for fourteen months, he has been told three different things by three different people, and he wants somebody to make a phone call. Your caseworker cannot make that call yet, because under the Privacy Act of 1974 a federal agency will not discuss his file with a congressional office without his written authorization. So the first thing that happens is a form. He signs it. It goes in a folder. Somebody scans it, eventually.

Meanwhile the same office is holding roughly forty other open cases across the Department of Veterans Affairs, Social Security, immigration services, the IRS, a housing authority and the passport agency. Each has a different liaison, a different response rhythm and a different definition of urgent. And in the background, twelve thousand letters and emails have arrived this month about a single bill, all of which need a reply that reflects the member's current position, which changed after the committee markup.

The systems in this market are Intranet Quorum from Leidos, which many offices have run for years and which does hold the whole model in one place, Fireside21, which is built specifically for congressional offices and is genuinely good at correspondence, and Indigov, which is the newer entrant focused on response time. They are all reasonable choices for a single congressional office. Where they leave gaps is at the edges: state legislative chambers with their own rules, statewide offices with many district locations and shared casework, governor's constituent services teams, and large city or county offices that have all the same problems and none of the products aimed at them.

Problem 1: no work can begin until a piece of paper is signed

The privacy release is the gate. Until it is signed and on file, your caseworker cannot ask the agency anything specific. In most offices the release is a PDF, printed, signed, scanned and filed by hand, and a real share of cases stall there because the constituent never sent it back and nobody followed up.

Packaged systems store the release as an attachment on the case. That is storage, not workflow. Nothing tells you that eleven cases have been waiting more than ten days for a signature, and nothing chases the constituent automatically.

What a custom build does: make the release a first-class object with a state, an expiry where your policy sets one, and an escalation path. Electronic signature is the obvious win, and it is legally straightforward for most releases, though agencies vary in what they accept, so the system should support both a signed electronic version and a scanned wet signature on the same case. Then the case status genuinely reflects reality: awaiting authorization, authorized, submitted to agency, agency responded. Your chief of staff can see the number of cases that never started, which in most offices is a number nobody currently has.

Problem 2: casework is mostly waiting, and waiting needs to be managed

Once the inquiry goes to an agency liaison, your office's job becomes follow-up. There is no service level agreement. There is a liaison who is helping fifteen other offices, an inbox, and the fact that the squeaky wheel genuinely does get attention. A good caseworker knows to re-contact at a certain interval, to escalate to a regional office at a certain point, and to call rather than email for certain case types.

Most systems model this as a task with a due date. That is not enough, because the right cadence differs by agency and by case type, and because the knowledge of what actually works with a specific liaison is exactly what walks out the door when a caseworker leaves.

What a custom build does: encode the follow-up pattern per agency and per case type as a template that generates the next contact automatically, then records the method and the outcome. Every inquiry, every reply, every phone call sits on one timeline. When a caseworker leaves, the new person opens the case and sees what has been tried. Aging reports by agency show which relationships are working and which need a call from the district director, which is a conversation the member can actually have with a regional administrator because you have the specifics.

Problem 3: correspondence is a completely different business sharing the same inbox

Casework is dozens of complex individual matters. Correspondence is thousands of letters on a few dozen issues, needing an accurate, timely and personal-sounding reply. Treating them as one queue is why offices fall behind on both.

Correspondence has its own machinery: incoming mail is coded to an issue, batched, matched to an approved response text reflecting the member's current position, personalized, approved by the right staffer and sent. When the position changes after a vote, everything queued on that issue needs re-approval before it goes out. Getting that wrong means a constituent receives a letter stating a position the member no longer holds, and that letter will be screenshotted.

What a custom build does: hold positions as versioned objects with an owner and an approval date, and bind every outgoing letter to the version it used. Incoming mail is auto-coded by topic with a human confirming, batches assemble by issue and stance, and approval is one screen rather than a chain of emails. Franking rules matter here as well: mass communications from congressional offices are regulated by the franking rules, including restrictions in the period before an election, so the system needs to know the difference between a reply to an individual constituent and a mass communication and treat them differently. Confirm the current thresholds with the Franking Commission, and build so that the distinction is enforced rather than remembered.

Problem 4: half the work is deciding whether this person is yours

Offices only serve their own constituents, and a constituent's address determines the answer. A caller from two blocks outside the line belongs to a colleague, and the polite handoff is part of the job. Address quality is therefore not a data hygiene issue, it is an operational one.

What a custom build does: validate the address at intake, resolve it against current district boundaries, and show the caseworker the answer immediately along with the correct referral if it is not yours. Addresses get re-verified when boundaries change. The referral itself becomes a record, so the office can show how many people it helped find the right office, which is a real service and currently invisible.

Problem 5: the office turns over, and the record has to survive

Staff turnover in legislative offices is high, and members leave. The status of a congressional office's records is unusual: they are generally treated as belonging to the member rather than as federal records, and offices are encouraged to arrange for their papers to go to an archive at the end of service. Confirm the specifics with the Clerk of the House or the Secretary of the Senate, or with your chamber's counsel if you are at state level.

The practical consequence is that your system must be able to produce a complete, structured export of everything, with attachments, on demand. Not a database backup that only the vendor can read. A future archivist, a successor office negotiating file transfers for open cases, and your own counsel all need it. Offices that discover at the end of a term that their records are locked in a format only a vendor can open have created a problem for themselves that nobody in the building has time to solve in January.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape is this. A focused first release covering constituent records, case intake with privacy release workflow, agency inquiries with follow-up automation and caseworker views runs $65,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding high-volume correspondence with versioned positions and batch approval, district verification, events and outreach, reporting for the chief of staff, and archival export runs $160,000 to $350,000 phased over 6 to 12 months.

What drives cost up in legislative offices specifically: the number of offices sharing one system and the rules about who can see whose cases; multi-member deployments, where a chamber wants one platform and each member wants their own walled data; correspondence volume, since the difference between three thousand and three hundred thousand letters a month is an architecture decision; language requirements in districts where they are substantial; and integration with incoming mail routes, which differ between chambers and levels of government.

What keeps cost down: starting with casework only. Correspondence can stay where it is for a term while the case side proves itself, and casework is where constituents actually judge the office.

Build versus buy, and when buying is clearly right

Buy if you are a single congressional office. Fireside21 and Indigov are built for exactly your shape, cost far less than a build, and include the mail routing plumbing you would otherwise have to solve. Intranet Quorum remains a defensible choice for an office already running it with staff who know it well. There is no honor in building what you can rent for a fraction of a staffer's salary.

Build when two or more of these are true. You are a state legislative chamber or a large council trying to serve many members with one system and rules about data separation that no product implements. You are a statewide or governor's office where casework spans multiple regional locations and several state agencies with their own liaison structures. You have a specialized caseload, such as an ombudsman function or a program with statutory deadlines, that a correspondence-first product cannot express. Or your current system's export is a dead end and archival obligations have become a real risk.

The tipping point is usually not volume. It is whether your office's structure differs from the single-member congressional office these products were designed around.

How to choose a developer for casework systems

Ask them what a privacy release is and why it gates the case. A developer who has worked in this space answers immediately and asks whether you accept electronic signature for each agency. One who treats it as an attachment field will build you a document store with a case-shaped label on it.

Ask how they would handle a position change on a bill with correspondence already queued. The right answer involves versioned positions, binding each letter to a version, and holding queued items for re-approval. Anything vaguer than that will eventually send a constituent the wrong stance in writing.

Ask what the export looks like. Request a sample structure covering cases, contacts, documents and correspondence with attachments intact, and confirm you can generate it yourself without asking the vendor. This is an archival requirement, not a nice to have.

Ask who owns the code and get it in writing before kickoff. The office or the chamber should own the repository, the cloud accounts and the right to hire another firm. Constituent records are among the most sensitive data any public office holds, and they should never live somewhere you cannot leave. At Digital Heroes the client owns the code from the first commit.