For counties, cities, and state agencies

Your residents cannot take their business elsewhere. That is the whole problem.

A commercial operation with a slow queue loses customers and learns from the churn. You do not get that signal. Residents wait, call again, escalate to somebody elected, or go without a benefit they qualified for — and only the third of those ever reaches you as information.

What service delivery looks like from the counter and from the phone

The phone lines are open during the hours most residents are at work. Somebody who calls at lunch reaches a queue, waits, and hangs up to go back to their shift. That call is recorded as abandoned, which is filed as a volume statistic rather than as a resident who still needs the thing they called about.

An application arrives missing one document. It goes into a pending status, a notice is generated, and the notice is written in the vocabulary of the programme rather than of the person receiving it. Some residents understand what to do. Others read it as a denial and stop. Both outcomes look identical in the system: pending, awaiting applicant.

Caseworkers are carrying more than the caseload standard, and the standard was set when the programmes were simpler. The most experienced ones are doing the work and also answering the questions of the newest ones, which is invisible in every workload measure and is the actual reason throughput holds up.

Then a resident calls a commissioner. That escalation gets worked immediately, by someone senior, ahead of everyone who waited properly — which is the correct human response and is also a queue-jumping mechanism that rewards knowing whom to call.

And the budget cycle does not move at the speed of any of this. A staffing request has to be justified at a meeting, months in advance, against other departments making the same request, using data assembled by hand by the people who are already the constraint.

Public records requests arrive on top of everything, with their own statutory clock, worked by the same staff.

The measure you are asked for is volume. The measure that matters is waiting.

Service systems record applications received and determinations issued, and do not record how long a resident waited between them or why — so the number that would justify a staffing decision is the one number nobody can produce.

This is why the budget conversation goes badly. "We are overwhelmed" is a claim. "Applications wait nineteen days, sixteen of which are queue time at one step, and here is that step" is a finding — and a finding survives a public meeting in a way a claim does not.

It is also why adding staff sometimes disappoints. Capacity gets applied where the volume is visible, and the delay is frequently somewhere else entirely: a verification waiting on another agency, a document a resident did not understand they needed to send, a determination sitting for a supervisory review that one person performs.

Separating those is the whole exercise. Time a resident waits because work is being performed is a capacity question. Time they wait because nobody has picked the case up is a queue question. Time they wait because they did not understand a notice is a communication question. Those have three different answers and only one of them costs headcount.

And the routine calls are their own category. A large share of contact is people asking where their application is, what a notice means, and what document to send. Answering those consistently, in plain language, on a channel residents actually use, is work that does not require a caseworker — and every hour of it currently comes out of caseworker time.

What changes for the resident, and what you can show the board

Where an application actually stops — measured by elapsed days per step, split into work, unworked queue, waiting on the resident, and waiting on another agency.

Residents who abandon rather than complete — measured by applications going inactive after a notice, distinguished from those correctly closed as ineligible.

Routine contacts handled without a caseworker — measured by status, next-step and document questions resolved on first contact, against the same volume before.

Calls that arrive outside your open hours — measured by contacts received and resolved outside counter hours, against abandoned calls in the same window before.

Cases approaching a statutory deadline — measured by cases surfaced before the clock expires, against breaches found afterwards in the prior period.

Escalations through elected officials — measured by volume of constituent escalations, and how many concerned a case already flagged as stalled.

The evidence behind a staffing request — measured by a step-level wait profile produced from the work itself rather than assembled by hand for the meeting.

any eligibility determination, denial, appeal decision, or exercise of programme discretion. Nothing here decides whether a resident qualifies for anything. Those determinations belong to your staff under your programme rules, and a vendor offering to make them is offering you a due-process problem.

Working with systems you did not choose and cannot replace

Much of what holds your case data was procured a long time ago, is shared with the state, or is maintained under a contract you did not write. This reads those systems through whatever documented interface they expose, and where none exists, that limitation is reported rather than worked around by automating a screen.

Nothing is migrated. No second record of a resident is created. Your system of record stays the system of record, which matters more here than commercially, because a second copy of a case status is a public-records problem as well as a data problem.

And the procurement question is answered honestly rather than sidestepped: an observation phase can usually be scoped small enough to fit existing authority or a cooperative vehicle, and if it cannot, that is a real constraint to establish at the beginning rather than after six months of scoping.

Resident data, public accountability, and access for everyone

Resident data collected for a programme is used for that programme. It is not used to train anything serving another organisation, and it is not combined across programmes without a lawful basis you established. In a government setting that is not a preference — it is the condition on which residents were required to hand it over.

Every action against a case carries a receipt naming who did it, under what authority, at what time. That record serves three purposes here rather than one: operations, audit, and answering a public records request without a discovery exercise.

Accessibility is treated as an obligation and not a feature. Any resident-facing surface is built to meet the standard your obligations require, and where an existing surface does not, that gap is named. A service a resident cannot use is not a service they were offered.

Language access is part of the same commitment. A resident who needs another language should not be given a longer wait as the price of being served.

Procurement, the security office, legal — and the public meeting

The review here has a step commercial buyers do not have: at some point this is discussed in public, by people who are not technologists, in front of residents who are affected. That argues for a scope that is easy to describe truthfully in one sentence — and "we are measuring where applications wait, and nothing about eligibility changes" is such a sentence.

Procurement is the practical constraint. An observation phase is usually small enough to fit an existing vehicle or a cooperative agreement, and it is worth establishing which one before scoping rather than after.

We do not claim certifications we do not hold. On the federal question specifically: we hold neither a FedRAMP authorization nor a FedRAMP certification, and where a state programme inherits a federal requirement, that is a scoping question with a real answer rather than a claim to be smoothed over.

One programme, one queue, observed before anything is delegated

A single programme and a single queue within it — intake, verification, or the routine contact line — observed read-only, with no authority to contact a resident or alter a case.

Observation contacts nobody, determines nothing, and changes no resident’s status. It produces the wait profile for that queue: how long applications sit, at which step, waiting on what, and how often a resident goes inactive after a notice rather than after a determination.

That profile is the artefact worth having regardless of what follows. It is the evidence a staffing request has been missing, and it is defensible in a public meeting because it was measured rather than assembled.

If you continue, the first delegation should be the routine contact — status, next step, what to send — on a channel residents already use, with your approved language, a written authority, and every determinative question escalating to your staff by rule.

Questions buyers actually ask

We cannot have a vendor making decisions about residents’ benefits.

Nothing here determines eligibility, issues a denial, decides an appeal, or exercises programme discretion — and that boundary is written into scope before anything is connected, not asserted afterwards. What can be delegated is answering where an application is, what a notice means, and which document to send. If a step cannot be cleanly separated from a determination, it stays with your caseworkers.

Our procurement process will take longer than the problem will wait.

Frequently true, and it is worth establishing at the start rather than discovering at month four. An observation phase is small and read-only, which often fits an existing vehicle or a cooperative agreement your entity already holds. Bring your procurement officer into the first conversation rather than the fifth — and if no vehicle fits, that is a real answer and better known in week one.

Our case system is old and the vendor charges for every interface.

Then the honest scope may be narrower, and it should be priced that way. Where a documented interface exists, it is used; where it does not, the limitation is reported as a limitation rather than worked around by automating a screen — a screen-scraped workflow breaks silently at the next upgrade and would break on a resident’s case. If the interface cost exceeds the value of the measurement, the correct decision is not to proceed.

How do I explain this at a public meeting without it sounding like we are replacing staff with a machine?

By describing the scope accurately, which is why the scope is written to survive being read aloud. In the first phase nothing is delegated at all — you are measuring where residents wait. In the second, what is delegated is the repeated status question that currently consumes caseworker time. The truthful framing is that caseworkers spend more of the day on cases and less of it on the phone explaining a notice, and it is truthful because it is what the scope says.

Our programme inherits federal requirements. Are you FedRAMP authorized?

No. We hold neither a FedRAMP authorization nor a FedRAMP certification, and stating that plainly is more useful to you than a qualified answer. Where your programme inherits a federal requirement, that determines what deployment is possible, and it is a scoping question to settle at the beginning. If the requirement cannot be met for your programme, you should have that answer before procurement rather than during it.

Residents in our county do not all have smartphones or reliable internet.

Which is why the surfaces are built for a slow connection and an old device rather than assuming otherwise, and why the phone remains a first-class channel rather than a fallback. A digital service that only works for residents with good connectivity redistributes access rather than expanding it. Where a resident needs another language or an accessible channel, that should not carry a longer wait as its price.