Replacing PDF forms with online forms staff can maintain

Reference article · 5 min read

Most agencies did not choose to standardize on PDF forms. They accumulated them. A program needed a form, someone built it in a word processor, a later staff member saved it as a PDF, and it has been on the website since. The result is a library nobody owns, in which residents print, hand write, scan, and email documents that staff retype into a system of record.

Replacing those forms is mostly an inventory and process effort with a technology step in the middle. Agencies that struggle usually buy a forms product first, then find that half the forms cannot be converted until someone decides who approves them.

Build the inventory, then rank it

Look past the website. Forms live in counter racks, shared drives, multi page packets, email templates, and internal processes that never reach the public. For each one, record the owning program, the legal basis if there is one, an estimate of annual volume, who receives the submission, which system the data ends up in, and whether it involves a signature, an attachment, or a payment.

The inventory usually surfaces duplicates, forms still posted for programs that ended, and forms whose owner cannot be identified. Retire those before converting anything.

Then rank by volume together with staff handling time, how often submissions arrive incomplete, and whether a deadline concentrates the work. Release high volume forms with simple processing first: they prove the pattern and produce a visible result. Save the form with seven approvers for later.

Redesign the process before digitizing it

A web form that reproduces the same sixty fields and the same three desk review is a faster way to run a slow process. Walk the path from submission to outcome with the people who process the work before you build anything.

• Question every field. Ask what decision each field supports and what happens if it is blank.
• Do not ask for data you already hold. Parcel and account numbers usually sit in a system that can be looked up or prefilled.
• Separate statute from habit. Some steps exist because law requires them. Many exist because a manager once wanted a second look.
• Use conditional logic instead of instructions. Show applicants only the questions their answers make relevant.

Choose among three kinds of tools

The right answer depends mainly on where the data needs to land.

• A dedicated forms product. Quick to publish, usually priced per form or per submission. Good for intake that ends in a queue, weaker when the work becomes a case with a long life.
• A workflow or low code platform. Handles routing, approvals, case tracking, and integration more capably, at the cost of more configuration and governance. Worth it when many forms share a review pattern.
• The form capability inside a line of business system. Permitting, tax, utility billing, ERP, and 311 systems often include forms or portals. Data lands in the system of record with no integration to build, though design flexibility and licensing may be limited.

Decide on a default and a rule for exceptions, or each new system will arrive with its own form builder.

Signatures, attachments, payments, and routing

• Signatures. Federal ESIGN and state adoptions of UETA generally give electronic signatures legal effect, with exceptions for certain document types, and some rules still call for wet signatures or notarization. Confirm current requirements with counsel, then match assurance to risk.
• Attachments. Set file type and size limits, scan uploads for malware, and decide where files are stored, how they reach the system of record, and how long they are kept.
• Payments. Use the cashiering and merchant services integration the agency already has, keep card data out of agency systems with a hosted payment page, and define what happens when payment fails.
• Routing. Route to roles and queues, never to a named individual, and allow delegation for absences. Give applicants a confirmation number, status notifications, and a way to supply a missing document without starting over.

Accessibility and ownership after go live

Accessibility is a legal obligation, not a refinement. The Department of Justice has adopted a rule under Title II of the Americans with Disabilities Act setting WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile applications, with compliance dates that differ by entity size. Requirements change, so verify them with the official source or your counsel. In practice this means keyboard operability, real labels, error messages that name the problem, sensible handling of session timeouts, and testing with a screen reader rather than an automated scanner alone.

Decide before launch who owns changes afterward. Name a form owner in each program, a small group of trained administrators, and a written path for requesting changes. If every wording fix requires a vendor ticket, forms drift back to PDF.

What to ask vendors and what to put in the contract

1. Can a trained staff member add a field, change wording, or adjust routing without vendor involvement, and can they demonstrate it live?
2. How does pricing change as form count and submission volume grow, and how many administrator seats are included?
3. Provide a current accessibility conformance report and describe how defects found after award are remediated.
4. How are form definitions, submissions, and attachments exported in a usable format?
5. Which integration methods are supported for the systems the agency already runs?

In the contract, state that the agency owns its form definitions, submissions, and attachments, with a complete export available at no added cost during the term and at termination. Require accessibility conformance with a remedy if it is not met, include administrator training, and confirm that routine form changes carry no per change fee. HQT works with state and local agencies on forms modernization, including process review, platform selection, and integration with systems of record.

Frequently asked questions