Why I Still Review Prices After Automating the Monitor

While maintaining a third-party service price monitor, I encountered a recurring set of changes. Four prices had already been checked, confirmed and reported, but the next weekly scan flagged them again.

The initial investigation focused on the human-checked values. I pointed out that they reflected the official pay-as-you-go prices at the time; we could not start by assuming they were wrong. Tracing the historical records revealed that the confirmed prices had not been fully written back to the baseline.

I was responsible for deciding what should be compared and how exceptions should be handled. With AI assistance, I changed scripts, review sheets and operating notes. Repeated alerts were the visible symptom. The underlying issue was how a confirmed decision would reach the next run.

Compare billing items instead of whole pages

An earlier version compared webpage content. Its detected changes included layout, scripts and dynamic content, none of which necessarily meant the billing rules had changed.

I narrowed the comparison to billing items: which service, which usage, what value, in which unit and under which plan. The webpage remains evidence; a confirmed billing record becomes the comparison baseline.

During this work, I also separated one service’s monthly and annual plan allowances into two records. They included different allowances, so a single row did not describe a stable comparison object. Splitting them added maintenance work, but was necessary for deciding whether something had changed.

An inaccessible source or a unit that cannot be matched goes to review rather than directly becoming a confirmed price change.

Trace prior decisions before repairing the baseline

On a later check, we found records showing that the prices had already been confirmed and reported. The human-entered values were correct. The script, price detail records and machine-populated column still held the old baseline, so the same changes entered review again.

Closing the issue required several actions: updating those locations from the confirmed decisions, closing the original review records and duplicate candidates, and checking that the machine and human-checked values now agreed. I did not stop when the alerts disappeared.

Targeted retesting no longer detected the affected changes. The full check still encountered network and synchronization problems. The records kept those outcomes separate rather than treating a passing local retest as a completed full run.

Fix the review logic as well as the values

Updating these old values alone would not explain what the next reviewer should do.

One branch in the review script needed correction. A human-checked value agreeing with the official source is not a reason to skip the item when the machine baseline is still outdated. In that case, the confirmed result still needs to be applied. The corresponding skip condition applies only when the current machine value also agrees with the official source.

I also changed duplicate detection. The same pending change should not become a new candidate merely because its notification status changed. Deduplication no longer depends on whether a notification has been sent.

Both changes went into the review script. The operating instructions also became explicit: after confirmation, update the script baseline, price details and machine column, then close the corresponding review record. People still confirm the result; notification status no longer stands in for that follow-through.

A refresh must not erase human judgment

Human-checked values and notes also needed protection. A normal refresh updates only machine-owned fields. Starting an entirely new round of review requires an explicit decision about the human columns, rather than clearing them on every sync.

When rows change, old manual values must not follow their row numbers onto different billing items. Machine data, human judgments and their relationship to the underlying objects all need to remain connected.

I separated current state from history. The first identifies pending items; the second preserves confirmation evidence and changes. That makes it possible to trace a discrepancy as we did here, instead of being left with two columns containing different numbers.

Notifications should point to the right problem

This round also corrected a misleading notification. It said the collection records were empty, when the actual issue was a parsing failure for one billing item. Records existed, but the message sent the investigation in the wrong direction.

I kept the existing schedule and recipients and changed the message to identify collection exceptions or items needing confirmation, with a reference to the relevant records. Overall run health comes from the run summary: whether required steps finished, failures remain or items still need investigation. One successful service cannot stand in for the full result.

The final changes included more than updated prices: comparison objects, review branches, duplicate detection, protection of human fields and notification wording. Each addressed a different source of rework.

If I were to reduce manual effort further, I would first separate time spent understanding plans, units and conditions from time spent cleaning up missed writes, mismatched records or duplicate alerts. The former requires judgment. The latter already has identifiable defects to fix.

This article is based on historical work records and validation results. AI assisted implementation and checks. Supplier values and internal staff details are omitted. The project's operating approach changed later; this is not a current operating manual.