Every name in the wheel, accounted for.

The gap in the jury management system market

Jury administration is a small department doing high-stakes work with tools that were never designed for it.

Most jury management software on the market was built for large metropolitan courts: courts with an IT department, a dedicated project budget, and enough summons volume to justify a six-figure implementation. Those platforms are capable. They are also priced, scoped, and configured for a scale that most American courts never reach.

The result is a wide middle ground of jurisdictions running jury operations on whatever they can hold together: a DOS-era system nobody remembers installing, a set of linked spreadsheets, a mail-merge template, and a filing cabinet. The work still gets done, because jury clerks are resourceful, but with no audit trail, no way to reproduce a draw, no defensible record of what was mailed to whom, and one person in the office who knows how any of it works.

EmpanelJMS exists for those courts. It covers the full lifecycle, source list to summons to service to payment, at a scale and price point that fits a jurisdiction summoning a few thousand jurors a year rather than a few hundred thousand. Nothing in it is a stripped-down version of something bigger. It was designed from the beginning for this size of court.

One platform, many jurisdictions

EmpanelJMS is multi-tenant by design, which is a capability rather than a requirement. Most installations serve a single court, and that court is the only jurisdiction in its database. The architecture matters when it is needed: a statewide deployment covering every county, a judicial district or circuit where two or three counties share a system, or a county that adds its municipal courts later.

Where jurisdictions do share an instance, separation is structural. Every record — juror, summons, panel, payment, notification — is bound to a jurisdiction identifier enforced at the data layer, not merely filtered in the interface. Staff in one county cannot see, search, or report on another county’s jurors, and a single county installation is subject to the same enforcement rather than a looser version of it.

What that architecture buys a court is configuration without custom code. The things that vary from county to county are settings, not development work:

• Term length and service model: one day, one trial, one week, or a term of court
• Per-diem rates, tiered by day of service, plus mileage rate and reimbursement rules
• Summons and questionnaire wording, letterhead, signature blocks, and return address
• Qualification and eligibility questions, and what each answer does to a juror’s status
• Source lists accepted, and how often they are refreshed
• Court time zone, business calendar, and holiday schedule
• Notification channels, timing windows, and message content
• Status codes, disposition reasons, and the vocabulary your clerks already use

A jurisdiction’s jury process is shaped by its state statute, its local rules, and thirty years of accumulated practice. A platform that forces a court to abandon its own terminology in order to fit the software is one the staff will fight for years. EmpanelJMS bends toward the court.

Cloud or on-premises deployment →

The master wheel

Everything downstream depends on the wheel being right. EmpanelJMS treats source list intake, qualification, and random selection as the part of the system that has to survive a challenge.

Building the wheel

Source lists arrive in whatever shape the supplying agency provides: voter registration extracts, driver’s license and state ID files, tax rolls, utility lists. EmpanelJMS imports them with a mapping profile per source, normalizes names and addresses, and standardizes addresses so duplicate detection actually works. Duplicates are identified across sources, not just within them, so a resident on both the voter roll and the DL file is one person in the wheel rather than two.

Scrubbing the wheel

The complaint we hear most often from counties is not about technology at all. It is that the same names keep coming back — the resident who died three years ago, the citizen a judge permanently excused, the person who moved out of the county — summoned again, year after year, because the last system had no memory. Every one of those wasted summonses is postage spent, a clerk’s time answering the resulting call, and a citizen’s trust in the court eroded a little further.

EmpanelJMS solves this with a persistent suppression list. When a person is marked permanently excused, permanently disqualified, or deceased, that determination is recorded once and enforced on every future wheel build automatically. It is not a note in a file that a new clerk has to know to check; it is a rule the system applies before selection, every time. Once someone is properly suppressed, they do not get summoned again, which is exactly the behavior counties assume they are already buying and so often are not.

Residency is enforced the same way, with precision. EmpanelJMS geocodes each address and evaluates it against the jurisdiction boundary to within a tenth of a mile, so a citizen who lives just outside the county line is not summoned to serve where they are not eligible. Coarse, ZIP-code-level residency checks miss exactly these edge cases; a tenth-of-a-mile determination does not.

The system then applies the jurisdiction’s remaining exclusion rules before selection ever happens: prior service within the statutory window, age limits, and any locally maintained exclusion list. Each exclusion is recorded with its reason, so a name that did not make the wheel can be explained.

Addresses go stale. People move, and a summons sent to a former address is a juror who never had the chance to respond, and, in aggregate, a wheel that quietly under-represents the parts of the population that move most often. EmpanelJMS runs the wheel through NCOA (National Change of Address) processing on a regular cycle, updating addresses of record against the USPS move database before summonses go out. The result is a higher deliverable rate, fewer wasted certified-mail costs, and a wheel whose addresses reflect where people actually live rather than where they lived when the source list was compiled.

Drawing from it

Random selection in EmpanelJMS is reproducible. When a draw is executed, the system captures a snapshot of the eligible pool as it existed at that moment and stores it alongside the draw. Months or years later, when a defense motion asks how a particular panel came to be constituted, the court can produce the exact population the names were drawn from, the parameters used, and the resulting order.

This is a deliberate and unusual design decision. Many systems will tell you who was selected. Fewer can tell you what they were selected from. The difference only becomes visible when someone challenges the array, precisely the moment a court cannot afford to be reconstructing history from backups.

Draws can be executed for a term, a week, a specific trial date, or a supplemental panel when the original pool runs short. Each draw is a distinct record with its own audit trail.

Summons production

Once names are drawn, the summons has to go out: correctly, in bulk, and looking like it came from a court rather than a marketing department.

EmpanelJMS generates summons documents as print-ready PDFs from jurisdiction-specific templates. Templates use a managed merge field library, so the fields available to a clerk are the fields the system can actually resolve: juror name, address, juror number, report date and time, courthouse location, parking and transit instructions, response deadline, the presiding judge’s signature block, and any custom field the jurisdiction defines. Merge fields resolve per jurisdiction, a common source of cross-tenant defects in systems that grew into multi-tenancy rather than starting there.

Each summons carries a barcode encoding the juror record. That single decision pays for itself repeatedly: it makes check-in a scan rather than a lookup, lets a returned questionnaire find its way back to the right record automatically, and makes it possible to process a stack of mail in minutes.

• Batch PDF generation for print vendors or in-house printing, with duplex and form-feed control
• Certified mail and first-class variants, with the certified tracking number captured against the juror record
• Second notices and delinquency letters generated from the same template system
• Undeliverable and return-mail handling, with automatic status changes and address flagging
• Reprint of an individual summons at the counter without regenerating the batch

How jurors respond

The juror portal is the part of the system the public sees, and it is the part that determines how much of your staff’s week is spent on the phone.

A summoned juror can go online, authenticate with their juror number and a verification detail, and complete the entire response: the qualification questionnaire, a request for excusal or deferral with supporting reasons, contact information updates, and an accessibility or accommodation request. They can check their reporting status, view directions and parking, and download or display their badge.

Getting there should take one step, not several. Each summons carries a QR code that opens the portal directly to that juror’s record, so a juror with a phone in hand scans the paper in front of them and lands on their own response form: no typing a URL, no hunting for a juror number, no account to create. It is the same paper-to-screen bridge that drives response rates up without asking the juror to learn anything.

The portal is built to be usable by people who are not comfortable online: large targets, plain language, no account creation, no password to forget, and a mobile layout that works on the phone the juror actually owns. It is available in the languages the jurisdiction configures — Spanish alongside English is standard, and additional languages are a configuration rather than a rebuild — because a summons a juror cannot read is a barrier to participation, not just an inconvenience.

Alongside the portal, jurors can respond by telephone through the court’s existing line with staff entering responses directly, through the automated voice line, through the juror chat assistant, or by returning the paper questionnaire attached to their summons.

Chat, for the questions that are not on the form

Most juror questions are not qualification questions. They are “where do I park,” “what do I wear,” “my employer needs a letter,” and “am I still supposed to come in.” EmpanelChat answers those from the juror’s own live record and the jurisdiction’s own configured content, so a juror gets a correct answer at nine at night without a staff member on the other end.

Some questions should not be answered by software. During office hours the court configures, a juror can ask to speak with a person and be connected to your staff directly from the same conversation, with the juror already identified and the exchange so far visible, so the staff member is not starting from “what is your juror number.” Outside those hours the juror is told plainly when someone will be available rather than being left waiting on a reply that is not coming. Anything the assistant cannot answer with confidence is handed to staff as a task with the conversation attached, rather than being guessed at.

The effect on a jury office is the point. The routine volume — the same six questions, asked a few hundred times per term — is absorbed before it reaches the counter, and the questions that genuinely need judgment reach a person who has the context to answer them.

Language is a configuration, not a rebuild

All three public-facing channels — the juror portal, the chat assistant, and the automated voice line — operate in the languages the jurisdiction configures. Spanish alongside English is standard; additional languages are added as configuration rather than as a development project, and a jurisdiction can enable a language on one channel without waiting for the others.

A juror’s language preference is stored on the juror record, so it carries across channels. A juror who selects Spanish in the portal hears Spanish on the voice line and reads Spanish in chat, and the notifications they receive by email and text are rendered from the same preference. The court does not maintain three separate translations of the same instruction, and a juror does not have to re-declare their language every time they contact the court.

This matters beyond convenience. A jury is supposed to reflect the community it serves. A juror who cannot read the summons response form, cannot understand the standby instruction, and cannot ask a question in a language they speak is a juror effectively excluded from service, and a fair-cross-section problem in the making.

Reading the paper that comes back

This is where most jury offices lose their time. A clerk opens an envelope, finds the juror in the system, reads nine checkboxes, keys nine answers, reads the remarks, and moves to the next one. Multiply by several hundred per summons cycle.

EmpanelJMS includes a document intake pipeline that removes most of that keying. Returned questionnaires are scanned in batches: from a desktop scanner, a departmental MFP, or an existing scan-to-folder workflow. The system then:

• Identifies the juror by reading the barcode printed on the original summons, so no one has to look anything up
• Reads the checkbox responses using a vision model trained on the actual layout, handling how people really mark forms, X marks, partial fills, circles around the whole box, and corrections
• Transcribes handwritten remarks, address changes, and phone numbers into the record
• Applies the jurisdiction’s field mapping, because question three on one county’s form is not question three on anyone else’s
• Routes anything uncertain to a review queue with the scanned image beside the extracted values, so a clerk confirms rather than transcribes

Every scanned file is virus-scanned on arrival before it touches the processing pipeline, and the original image is retained against the juror record as the source of truth. Nothing is discarded because the system thinks it read it correctly.

Extraction runs against a configurable per-jurisdiction map of fields to page positions, so onboarding a new court’s questionnaire is a configuration exercise rather than a development project. Multi-page forms are supported.

Notifications

Most of the phone calls a jury office fields are variations of one question: do I have to come in tomorrow? A notification system that answers it before it is asked is the single highest-return feature in jury management software.

EmpanelJMS runs a scheduled notification engine that sends email and SMS on the jurisdiction’s own calendar. Schedules are defined per jurisdiction and per notification type, with a defined audience, a send window, and message content built from the same merge field library used for summonses.

Not every juror is online. For those who deal with the court by phone, still a meaningful share in many jurisdictions, EmpanelJMS drives an interactive voice line from the same schedules and the same message content. A juror can call a jurisdiction number, enter the identifier from the summons, and hear the current standby instruction — report, do not report, or call again — read from the same status the portal would show. The line is generated from the court’s typed message, so the phone tree never drifts out of sync with what everyone else is being told. The voice line speaks the languages the jurisdiction has configured, and answers each juror in the language recorded on their own record.

SMS is two-way. A juror can reply to a message to acknowledge receipt, ask whether to report, or request a callback, and the reply is captured against the juror record rather than lost in a carrier inbox. Recognized replies are answered automatically from live status; anything the system cannot resolve is routed to staff as a task instead of a dead end.

What gets sent

• Summons acknowledgement, confirming a response was received
• Reporting reminders in the days before the service date
• Nightly standby instructions: report, do not report, or call again tomorrow
• Group or panel-specific instructions when the standing message does not apply
• Deferral and excusal rulings, with the reason and any new date
• Payment issued notices
• Emergency closures and schedule changes, sent on demand

What keeps it trustworthy

The engine resolves the audience for each send at send time from live juror status, not from a list built the week before. It applies deduplication so a juror who qualifies through two schedules receives the message once. It records a content hash of exactly what was sent to each recipient, so the court can later prove the wording a specific juror received rather than the wording of the template as it exists today.

Delivery results come back into the record. Bounced email and failed SMS numbers are flagged against the juror so staff can correct them, and repeated failures surface rather than disappearing into a log file. Consent and opt-out state is tracked per channel and honored across every schedule automatically.

Each morning, staff receive a recap of what went out overnight: how many messages by channel and schedule, how many failed, and which jurors need attention.

The term of service

Once jurors report, EmpanelJMS becomes the floor management tool for the jury assembly room.

Check-in

Jurors check in by barcode scan from their summons or badge, by self-service kiosk, or at the counter by name lookup. Check-in stamps an arrival time against the service day, updates status, and immediately reflects in the assembly room roster. Late arrivals and no-shows are visible without anyone reconciling a paper list.

Panels and assignment

Staff build panels from the checked-in pool for a specific courtroom, judge, and case, in a randomized order the system records and can reproduce. Panel lists print for the courtroom, and the panel’s disposition — selected, struck, excused, returned to the pool — comes back into the record. Jurors returned to the pool are immediately available for the next panel.

Status changes during the term

Deferrals, excusals, postponements, and hardship requests are handled as ruled decisions with a reason code, the deciding official, a timestamp, and any resulting new service date. Nothing changes a juror’s status without a record of who changed it and why. Failure-to-appear tracking and show-cause workflows follow the same pattern.

Daily operations

• Assembly room roster with live counts by status
• Attendance recorded by service day, driving both payment and term completion
• Release and dismissal, individually or by group, with the corresponding notification
• Term completion and prior-service recording that feeds back into wheel exclusions

Paying jurors

Juror payment is the part of jury administration most likely to end up in an audit finding, and the part most often handled outside the jury system entirely, in a spreadsheet, then re-keyed into the county’s financial system.

EmpanelJMS calculates payment from recorded attendance. Per-diem rates are configured per jurisdiction and can be tiered by day of service, so a court that pays one rate for the first day and a higher rate thereafter is configuration, not a workaround. Mileage is calculated at the jurisdiction’s rate against a distance the system derives itself: each juror’s address is geocoded and the distance to the courthouse computed automatically, so staff are not looking up mileage by hand or trusting a number a juror wrote on a form. Round-trip and one-way handling is configurable, and rounding follows the arithmetic a court expects rather than the arithmetic a programming language defaults to, a small detail that produces reconciliation headaches when it is wrong.

Disbursement

• Check register export in a format the county’s financial system accepts, for courts that pay by warrant
• Donation of juror pay to a court-designated fund, captured at the counter or on the juror record, and reported separately
• Batch approval so payment runs are reviewed and released by an authorized user, not issued silently

Payment records carry the attendance days, rate applied, mileage, donation, and net amount, with a reconciliation report that ties the payment run back to the attendance it was calculated from. Year-end reporting thresholds are tracked per juror.

How juror payment and disbursement work →

Reporting and records

EmpanelJMS ships with the reports a jury office is actually asked for, and exports for the ones nobody could have anticipated.

• Yield reporting: summonses mailed, undeliverable, responded, qualified, excused, deferred, reported. The numbers a court needs to size its next draw correctly.
• Utilization: jurors summoned versus jurors used, panel efficiency, and days served per juror
• Demographic and representativeness reporting where the jurisdiction collects and is permitted to report the underlying data
• Payment and financial reports, including donation totals and outstanding disbursements
• Non-compliance: failures to appear, second notices, and show-cause candidates
• Communication history per juror, showing every notice sent and its delivery result
• Ad hoc export to CSV or Excel for state-mandated reports and one-off requests from the bench

Every material change to a juror record is written to an audit log with the user, timestamp, and prior value. That log is queryable by staff with the appropriate role; it is a working tool, not a black box that only a vendor can read.

See the constitutional compliance analytics →

Security and operations

A jury system holds names, addresses, dates of birth, partial identifiers, and in many jurisdictions the answers to questions about a citizen’s health, criminal history, and financial hardship. It is a sensitive dataset in a public institution, and it is a plausible target.

Background processing — the notification engine, scan pipeline, and scheduled jobs — runs on infrastructure configured to stay resident rather than idling out overnight. That sounds like an implementation detail. It is the difference between the standby message going out at four in the morning and the jury office discovering at eight that it did not.

Our full approach to security →

Getting off the old system

The hardest part of replacing a jury system is not the new software. It is thirty years of history in a format nobody supports, and a jury office that cannot stop operating while the change happens.

Integrated Jury Solutions has migrated courts off legacy platforms including DOS-era database systems, classic web applications, and file-based systems with no export capability worth the name. The approach is consistent:

• Read the actual data first. Not the documentation, not the schema diagram, not what the last vendor said it contained. The live data, field by field, including the columns repurposed a decade ago and never renamed.
• Map history that matters. Prior service records drive wheel exclusions and statutory eligibility. Those must come across accurately or the first draw on the new system is wrong.
• Run in parallel where the court wants to. A term of overlap costs a little duplicated effort and removes almost all of the risk.
• Convert the forms, not just the data. The summons the court has used for twenty years is reproduced, not redesigned, unless the court asks otherwise.
• Train on the court’s own records. Staff learn faster on jurors they recognize than on demonstration data.

Implementation timelines for a jurisdiction of typical size are measured in weeks, not quarters, and the people configuring the system are the people who built it.

Opinions we hold

Software reflects the judgment of the people who write it. These are the calls that shaped EmpanelJMS, stated plainly so a court can decide whether it agrees.