Link the roll to permits, sales, and new service connections

Make key events—building permits, completions, transfers, and utility connections—feed the property roll automatically or through a routine monthly process. This turns coverage from a one-off clean-up into a maintenance system.

• Planning, land, or utility processes are already functioning reasonably well.

• The city wants coverage maintenance to happen through normal government workflows.

• There is some institutional support for inter-agency cooperation.

• Agreements with partner agencies and a clear matching key or address standard.

• A routine for receiving, reviewing, and acting on incoming event data.

• Avoid this as a first move when basic record matching is still too weak.

• It is not a good fit where the relevant transactions happen mostly outside formal systems.

The political risk is usually low to moderate, but the city still needs to show that new records will be handled fairly and that residents are not being drawn into a process they do not understand.

The full card would help the city plan the event triggers, the institutional agreements, the monthly update process, and the exception-handling rules that turn permits, transfers, and service connections into routine register updates.

• Cross-match with permits, utilities, and land records

• Give each property one ID in one register

• Put routine coverage audits on the calendar.

Initial discovery drives are valuable, but the real test is whether the city can keep the roll current without repeatedly starting from scratch. Trigger-based updates are one of the most practical ways to do this because they connect the tax register to events that already happen elsewhere in government or in the market.

Turn routine external events—such as building permits, completions, sales, inheritances, subdivisions, or utility connections—into regular triggers for register updates.

A city that wants the register to update more continuously and has at least a few external processes or agencies that can realistically serve as triggers.

A first trigger stream that begins to feed usable changes back into the register, such as building completions or new service connections.

Choose the first trigger to operationalise and back the inter-agency arrangement needed to make it routine rather than exceptional.

Revenue administration with partner agencies such as planning, land registration, utilities, or licensing.

• The city already relies on formal or semi-formal processes such as permits, title transfers, or new service connections.

• Partner agencies are open to a simple operational arrangement, even if full systems integration is still far away.

• Leadership wants the register to evolve from a one-off project into a routine administrative process.

• Choose one trigger first and make it work before trying to connect everything.

• Agree the minimum data fields and the common key or location logic that will let records be matched and updated reliably.

• Clarify who is responsible for reviewing trigger data and who has authority to change the register.

• Decide whether the first trigger feed will be manual, periodic, or more automated.

• Choose whether the reform will simply update the register or also require tax ID or clearance checks within the partner process.

• Set a rule for exception handling so mismatches do not stall the entire process.

First 90 days

• Identify the first candidate trigger and negotiate a practical operating arrangement.

• Pilot the data handover or query process on a small sample of cases.

• Define the workflow from trigger receipt to confirmed register update.

6 to 12 months

• Run the first trigger process routinely and review exception cases every month or quarter.

• Measure how often the trigger data actually produce usable updates.

• Refine the fields, timing, and validation rules before scaling or automating.

12 to 24 months and beyond

• Add further trigger streams only after the first one is stable.

• Move toward more predictable or automated exchange where it is genuinely useful.

• Use the trigger logic to reduce the size and cost of future audit or discovery exercises.

• The city usually needs data-sharing authority or an MOU, and in some cases a rule requiring tax ID or tax clearance as part of a partner process.

• The arrangement should be narrow and practical enough to survive staff changes and routine bureaucratic pressures.

• Trigger-based maintenance needs named liaisons in each office, not just senior-level agreement.

• A small exception-review routine is critical because not every trigger will match cleanly to an existing record.

• One stable register and one location or ID logic make this reform much easier to sustain.

• Cities often sign ambitious agreements that never become operational because no one owns the daily workflow.

• Weak matching rules can create bad updates or rising backlogs of exceptions.

• If the tax office cannot act on the trigger data promptly, partner confidence may fall.

• Number of update events received from each trigger source.

• Share of trigger events converted into confirmed record updates.

• Average lag between the real-world event and the register update.

• Number of unresolved exception cases.

• This card depends on PT-COV-07 and PT-COV-13 for a usable register backbone, and it complements PT-COV-09 because good trigger flows reduce the burden on later audits.

• Which trigger source is easiest to operationalise first?

• Who reviews and approves updates coming from the trigger feed?

• What should happen when a trigger cannot be matched cleanly to a record?

• Will the city also use tax clearance or tax ID checks inside partner processes, or only data sharing?