Inside a 90-Minute Test of a 20-Hour County Backlog

The Lewis County Treasurer’s Office had a straightforward problem that had become a substantial time commitment. A municipal annexation project required the office to review approximately 1,300 parcel records, check information in the county’s property-tax application, and document the results in an Excel workbook.

About 300 parcels had already been completed. Roughly 1,000 remained.

The existing process worked and required manual navigation and data entry. At the Treasurer’s working pace, every 100 parcels required about two hours. Completing the remaining records was expected to take approximately 20 hours.

10 Fold Consulting worked with the Treasurer to examine whether the repetitive portion of the process could be handled through a small, locally operated automation. The goal was practical: reduce repetitive data entry while keeping uncertain records, tax determinations, and final responsibility with county staff.

During a roughly 90-minute working session, we documented the process, built a prototype with assistance from Claude, and tested it against records the Treasurer had already completed. Initial tests took about five seconds per parcel. If that rate held across the remaining records, the batch would take approximately 1.5 hours of machine runtime.

That figure is a projection from the initial tests. The available project record does not document a completed production run of all remaining parcels.

The issue

The work involved moving through the same basic sequence for each parcel:

1. Take a parcel number from the Excel workbook.
2. Search for the parcel in the county’s property-tax application.
3. Review the relevant summary, receipt, and tax information.
4. Identify the applicable payment amount and date.
5. Determine whether the record reflected a first-half payment or a full-year payment.
6. Enter the result in the correct spreadsheet fields.
7. Set aside missing, exempt, or conflicting records for follow-up.

The volume created the problem. The Treasurer already understood the records, the payment rules, and the exceptions. The number of hours required to repeat the same navigation and data-entry steps across roughly 1,000 remaining parcels was the practical limitation.

The process also included legitimate variations. A parcel could open on a different tab, have no current record, carry an exemption, or show values that did not align cleanly. Those cases required context and review. Any useful solution needed to handle routine records consistently while preserving uncertain cases for staff.

What the office was already doing

The office was resolving the project one parcel at a time. The Treasurer copied a parcel identifier from the workbook, searched the tax application, reviewed the available information, and entered the result back into Excel.

This approach was dependable because the work stayed in the hands of someone who understood the records. It also made exceptions visible as they appeared. Its weakness was the amount of senior staff time it consumed.

At an estimated two hours per 100 parcels, the remaining workload represented about 20 hours of focused manual processing. That estimate gave us a baseline against which to judge whether a prototype would be worth pursuing.

The proposed fix

We proposed a limited automation for the repetitive administrative steps. It would read the next parcel identifier from the workbook, search the tax application, collect the relevant payment information, and return the observed values to the corresponding spreadsheet row.

The automation was designed to route missing records, exemptions, and conflicting figures to county staff for review. The Treasurer would remain responsible for the final output and for any determination requiring subject-matter judgment.

The proposal used the county’s existing applications and workbook and focused on the narrow task that was creating the backlog.

What we reviewed before testing

Before running the prototype, we first needed to understand the process well enough to describe it in explicit steps.

The Treasurer demonstrated completed records and explained:

• which application screens and tabs contained the needed information;
• where each value belonged in the workbook;
• how first-half and full-year payments were represented;
• how the office handled exempt or government-owned parcels;
• what should happen when no current record was available; and
• which discrepancies required a person to review the record.

We also identified previously completed rows that could serve as known examples. Those records gave us a reasonable test set because we could compare the prototype’s output with work the Treasurer had already reviewed.

The operating conditions mattered as much as the process rules. Before broader use, the work needed a defined scope, an approved local environment, limited access to the applications required for the task, and a clear review path for generated code and test results.

Coordinating with county IT

The testing and development were coordinated with county IT network specialists. The use case, local processing approach, expected benefit, and boundaries of the prototype were reviewed so the work could proceed within a limited and managed scope.

The prototype ran locally on the approved county computer and interacted only with the applications needed for the parcel workflow. County IT also called for technical review of the generated code before broader use.

This coordination established practical limits for the project. It kept the test focused on a specific administrative process and made clear that a promising prototype still needed appropriate technical and operational review before it could be treated as a production tool.

How the prototype worked

Claude was used to help generate and revise the code. The Treasurer supplied the process knowledge, and we translated that knowledge into a sequence the software could follow.

At a high level, the prototype:

1. selected the next parcel identifier from the workbook;
2. entered that identifier into the county tax application;
3. navigated to the relevant record information;
4. collected the payment amount, payment date, and supporting values;
5. wrote the result to the appropriate spreadsheet row; and
6. flagged records that did not match the expected conditions.

Development was iterative. We tested one narrow behavior, compared what happened with what the Treasurer expected, adjusted the code or instructions, and tried again. That allowed the workflow rules to be refined without starting with a large batch.

Claude accelerated the coding process. The Treasurer supplied the policy, defined the workflow, interpreted the tax records, and reviewed the results. The software carried out the repeatable interface and data-entry steps.

How we tested safely and limited impact

Testing began with records that had already been completed manually. That kept the first comparisons within a known set rather than introducing the prototype across the full backlog.

We started with small actions and individual records. We then checked examples representing normal processing and known exceptions, including:

• a first-half payment;
• a full-year payment;
• a parcel with no current record;
• an exempt or government-owned parcel; and
• a record where the available figures did not agree.

For uncertain cases, the prototype preserved the available values and marked the row for review. It did not resolve the discrepancy on its own.

Several controls limited the impact of testing:

• the prototype ran locally on the approved computer;
• access was limited to the workbook and tax application used for the task;
• tests used previously reviewed records with known results;
• the team began with individual actions and a small number of records;
• exceptions remained visible for human review; and
• county staff retained responsibility for final accuracy and any consequential decision.

These controls made it possible to evaluate the idea in a limited environment. Broader use remained subject to the required review.

How we reviewed and verified the results

The Treasurer compared the prototype’s output with the results already recorded for the test parcels. Normal payment records were checked for the correct amount, date, and spreadsheet placement. Exception cases were checked to confirm that the prototype surfaced the issue rather than quietly forcing a result.

The early tests showed a processing time of about five seconds per parcel. Applied to the roughly 1,000 remaining parcels, that produced an estimated runtime of approximately 1.5 hours, compared with the 20-hour manual baseline.

The project record supports three conclusions:

1. The repetitive workflow could be represented in a working local prototype.
2. The tested records could be compared with known manual results, including exception cases.
3. The observed test speed suggested a meaningful reduction in repetitive processing time if performance held across the full batch.

The record does not establish that every remaining parcel was processed, that the projected savings were fully realized, or that all production-readiness reviews were completed. Those are important distinctions when describing a prototype honestly.

The practical outcome

The session produced a tested prototype and a clearer understanding of where automation could help. Routine records could move through a consistent sequence, while exceptions remained with the people accountable for the work.

For the Treasurer’s Office, the potential value was the return of time. Approximately 20 hours of manual effort could be reduced to a shorter automated run plus staff review of exceptions, provided the initial performance held and the solution passed the required reviews.

The broader lesson is modest and useful. When a knowledgeable employee is spending hours moving structured information between existing systems, a narrowly scoped automation may be worth testing. The work should begin with a clear manual baseline, known examples, defined exceptions, IT coordination, and a person who remains responsible for the result.

The companion executive brief summarizes the decision case and projected capacity return. Our guide to finding high-ROI AI use cases explains the problem-first discovery process, and the field guide to controlled browser workflows covers the operating controls behind bounded automation.

That was the approach taken with the Lewis County Treasurer: understand the work, keep the scope limited, test against known answers, and describe the outcome according to what was actually observed.

If a structured process is absorbing your team’s best hours, 10 Fold Consulting can help you map it, test the opportunity, and build a controlled solution.