Colorado requires pest control operators to notify sensitive individuals before nearby applications. The state has done the geographic work. The software hasn't caught up.
Colorado law requires licensed pesticide applicators to notify sensitive individuals at least 24 hours before any application made within 250 feet of their registered address. The notification rules are specific: multiple attempts are required unless made electronically, voicemail doesn't count, and any changes to a scheduled application require a new notification. Records of all attempts must be maintained.
Until July 2024, the state fulfilled its end of this requirement by mailing a printed booklet of registered individuals to every licensed applicator. The applicator's end — cross-referencing that booklet against upcoming jobs, making documented notification attempts, and maintaining records of compliance — was entirely manual.
The booklet is now an online, GIS-enabled database restricted to licensed applicators. The state has done the geographic work: it knows which registered addresses fall within 250 feet of any given property. That information is accessible. What doesn't exist is any connection between that database and the scheduling software pest control companies actually use to run their operations.
The state has done the geographic work. The gap is between a searchable government database and the software sitting on every applicator's desk.
A missed notification isn't just a customer service failure — it's a regulatory violation with potential licensing consequences. For a small pest control operator running dozens of jobs a day across multiple technicians, manually cross-referencing a registry against a live schedule is the kind of task that gets done inconsistently, documented poorly, and forgotten entirely when things get busy.
The people on the registry are there because pesticide exposure poses a genuine health risk to them. The notification requirement exists to protect them. The gap between a searchable government database and the software sitting on every applicator's desk means that protection depends entirely on human memory and manual process.
This is not a compliance awareness problem. Operators know the requirement exists. It's a workflow integration problem — the registry lives in one place, the schedule lives in another, and nothing connects them.
The compliance burden falls primarily on dispatchers and office staff, who are already managing a high-volume scheduling workflow. The current process asks them to add a manual lookup step against a separate government database for every job in the schedule — not once, but every time a job is added, moved, or changed.
The core feature is straightforward: property records in the scheduling software carry an adjacency attribute on the appointment — a flag indicating that a PSR-registered address falls within 250 feet. That flag is established by automatically syncing against the PSR database at booking time. The scheduler doesn't need to think about the registry at all. The software just knows.
Once an appointment with an adjacency notification requirement is created, the software queues the notification in alignment with the appointment's schedule. When the appointment is finalized, the software generates the tasks necessary for notification automatically — an automated queue for electronic notifications, a call list for manual ones. The workflow supports outreach beginning sufficiently ahead of the 24-hour window to allow multiple documented attempts.
Most days, no notifications will be required. The software must have a mechanism to surface a task on days when a sensitive registry call is required without it becoming background noise. The most workable approach: append sensitive registry calls to the normal daily call list, displayed differently in the UI — a bold border, a distinct background — so they're visible within the dispatcher's existing workflow rather than requiring a separate lookup step.
If an appointment with a sensitive registry notification requirement changes dates, the notification clock resets. The software prevents rescheduling that leaves less than 24 hours available for notice, surfaces an explanation to the user, and automatically clears the notification attempt history and "notification completed" flags. The notification re-enters the queue based on the updated appointment information. No manual reset required.
The notification workflow must reflect the legal distinctions that create liability. These are not just different contact methods — they are different workflows with different compliance requirements.
One attempt required. Triggers the 24-hour clock for any schedule changes.
Two documented attempts required. Door notice as last resort. Different escalation path.
Every attempt — successful or not — is logged with timestamp, method, and outcome. At the end of the job the record exists without anyone having to reconstruct it. Failed notifications escalate visibly: a job with an unresolved notification requirement approaching the 24-hour window is surfaced to the scheduler before the window closes, not after.
If the office has been unable to confirm notice prior to the appointment, responsibility passes to the field. When a technician opens an appointment with an unresolved notification requirement, the software surfaces a prompt to place a written notice on the door of the registered address before beginning service. The attempt is logged from the field, timestamped, and added to the compliance record automatically.
This fits into how a dispatcher already works rather than adding a new lookup step. The compliance burden shrinks to handling exceptions — the software handles the routine.
The state moved to an online system in July 2024. Whether that system exposes a queryable API — or whether integration would require a different approach such as scheduled exports or manual sync — is the first question any development effort would need to answer. Everything else depends on it.