Pothole Reporting with AI: Why a 2-Minute Call Beats a 5-Step App Submission

AI Pothole Reporting: What to Look For

The decision to add AI to the pothole-reporting channel is usually triggered by one of three things: a complaint cycle that landed in a council meeting after a high-profile pothole damaged a constituent's car, an after-action review on a storm season that exposed how poorly the city handles surge volume, or a public works director who finally calculated how much crew time gets burned on misrouted potholes that turn out to be on state highways or private roads. Here is the buyer checklist that comes up in every pothole AI evaluation.

• Native two-way integration with the city's 311 / CRM and work-order systems. Read the city's road inventory and GIS layer; write structured pothole reports into SeeClickFix, PublicStuff, Salesforce Public Sector, Microsoft Dynamics 365, Granicus 311, Qscend, or Accela 311; write the actual work order into Cityworks (Trimble), Cartegraph (OpenGov), Lucity, IBM Maximo, or Tyler Munis Work Orders. The AI must produce a record that flows into the same system the dispatcher would have used.
• GIS-aware jurisdiction validation. The AI must query Esri ArcGIS against the reported address in real time to identify whether the pothole is on a city street, a state highway, a county road, or a private drive. Routing decisions follow from that. Misrouted potholes burn crew time the city cannot recover.
• SMS photo upload integrated with the report record. The AI must offer the caller a secure SMS link to upload one or more photos that attach directly to the report. Photos make the difference between a work order that dispatches the right equipment and a work order that requires a second crew visit to scope the repair.
• Severity classification from conversation. The AI must classify severity from the caller's description - "small crack" vs "tire-eating crater" vs "wheel-bending hole" - and apply the city's severity-to-response-window rules. Severity drives crew priority and is one of the strongest predictors of which reports get resolved within the city's published SLA.
• Address validation with disambiguation. "There's a big pothole on Main Street" needs to become a specific intersection or block range. The AI must ask follow-up questions (nearest cross street, nearest address, distinctive landmarks) and validate against the address grid before filing the report.
• Duplicate detection. The AI must check the recent report queue for matching location and pothole description; when it finds a duplicate, it tells the resident "yes, that pothole is already in our queue, scheduled for repair on [date]" instead of opening a duplicate ticket. The duplicate-detection step alone can reduce ticket volume 15-30%.
• Damage-claim differentiation. When a caller starts the conversation with "your pothole damaged my car," that is a different workflow than a report-the-pothole conversation. The AI must distinguish the two, capture the structured damage-claim intake, and route to the city's risk management or insurance contact - not just write a pothole report.
• Bilingual or multilingual by default. Spanish is table stakes. Additional languages match the city's Title VI plan.
• Warm transfer to a public works dispatcher with full context. When the AI can't resolve (a unique situation, a question that requires a human, a caller who asks for one), the human shouldn't start at zero. Transfer must include the location, photos, severity classification, and the caller's name and contact.
• Resident callback when status changes. The AI offers to text the resident when the pothole is dispatched, when the crew arrives, and when the repair is complete. Closes the loop on the report and reduces "is anyone coming?" callbacks dramatically.
• Audit trail for liability defense. Every call recorded, full transcript, structured fields, GIS validation logged. Required when the city is named in a pothole-damage lawsuit and needs to demonstrate the report-to-repair timeline.
• Procurement path that does not require a year-long RFP. Cooperative purchasing or partner-held state master contract is usually the fastest path. Vendor should bring the documentation - capability statement, references, sample contract language - not make the procurement office build it.

The rest of this guide explains how each requirement is met in practice, what the operational picture looks like once the AI is live, and the numbers cities are reporting after the first quarter of deployment.

Why the Pothole-App Strategy Stalled

Most cities have spent the last fifteen years trying to push pothole reporting away from the phone. The economics are obvious - a structured app submission is faster to triage than a phone call, and the city does not have to pay a clerk to take the report. The technology has gotten better at every layer. Most cities have at least one of: a 311 mobile app, a SeeClickFix-style portal, a QR code on signage, an integration with Waze and Google Maps. Adoption has gone up. The phone has not gone down nearly as much as the strategy assumed it would.

The structural reasons are not hard to figure out once you look at who actually reports potholes. The typical pothole report comes from a resident who just drove over the pothole, did not love the experience, and wants to make sure the city knows about it. The reporter is in their car. They are at a stop light or a parking lot. They have the city's main number in their phone (or they just dialed information). They do not have the city's app installed. The 5-step path the app requires - download, sign up, find the pothole on a map, take a photo, submit - is a higher barrier than most reporters are willing to clear for one pothole. So they call.

The result across hundreds of cities is a consistent pattern. The app and the portal absorb a meaningful share of motivated reporters - frequent reporters who have already adopted the channel, hardcore civic users, people with technical comfort and time. The phone absorbs everyone else, plus the surge volume after storms or freeze-thaw cycles, plus the long tail of residents who simply prefer voice. Phone volume on the pothole channel typically sits at 50-70% of total reports for a mid-size city, even after several years of digital channel investment.

The cities that took this seriously stopped fighting the phone and started asking the harder question: how do we make the phone channel produce data as good as the app's? That is the question AI pothole reporting answers.

How AI Captures a Pothole Report End-to-End

Here is what a typical pothole report call looks like end-to-end with AI on the line.

1. The call is answered on the first ring, any hour. Morgan identifies the agency: "You've reached the City of Example pothole and road-condition reporting line. I can take a pothole report, a damaged-vehicle claim, or check the status of a previous report. What can I help you with?"
2. The caller describes the situation. "There's a big pothole on Oak Street right in front of 422 Oak, in the middle of the eastbound lane." Morgan parses the intent (new pothole report), the location, and the rough size descriptor.
3. Morgan validates the address against the city GIS. Behind the scenes, the AI queries Esri ArcGIS to confirm 422 Oak Street is a real address, in the city's jurisdiction, on a city-maintained street. If the address is ambiguous, the AI asks clarifying questions ("Oak Street between Third and Fourth, or between Fifth and Sixth?"). If the address is on a state highway, the AI routes to the state DOT (see the Jurisdiction section).
4. Morgan checks the recent report queue for duplicates. Within a configurable radius and time window, the AI checks whether the same pothole has already been reported. If yes: "Yes, a report was filed for that location two days ago, work order PW-2026-04827, scheduled for repair on Friday. Want me to add you as a follow-up contact in case there's an update?" No duplicate ticket created.
5. Morgan classifies severity through conversation. "How big is it - small crack, medium hole the size of a basketball, or bigger?" "Is it causing traffic to swerve around it?" "Is it on a curve or in a high-speed area?" Severity maps to the city's response-window matrix.
6. Morgan offers SMS photo upload. "If you can take a photo or two when it's safe, I can text you a secure link - photos help the crew bring the right equipment. Want me to send the link?" Photos attach directly to the report record. Most callers send at least one.
7. Morgan captures any additional context. Underlying drainage problem visible? Recent prior fill that failed? Damage to vehicles witnessed? These fields shape the repair approach.
8. Morgan files the work order into the city's system. The work order lands in Cityworks, Cartegraph, Lucity, or the city's other work-order platform with structured fields, GIS coordinates, severity classification, and any uploaded photos attached. Routing follows the city's configured rules (which crew, which yard, which priority queue).
9. Morgan confirms and ends cleanly. "Your report is filed. Reference number PW-2026-05014. Based on severity, the crew typically responds within 3 business days. Want me to text you when the crew is dispatched and when the repair is complete?" Total call time 90 seconds to 3 minutes.

For damage-claim calls ("your pothole wrecked my tire"), the workflow forks to a structured intake that captures vehicle info, the time of incident, the location, and the caller's contact, then routes to the city's risk management or insurance contact rather than opening a repair work order. The two workflows are distinct intentionally.

Call Types AI Handles for Pothole Reporting

Pothole reporting looks narrow on the surface but actually covers a wider mix of call types than most cities realize. Here is the typical split for a pothole-line AI deployment that has been live for a quarter.

New Pothole Reports

The highest-volume category. Authenticate location, validate GIS, check duplicates, classify severity, capture photos, file work order. Fully automated end-to-end.

Status Lookups on Existing Reports

"I called in a pothole two weeks ago, what's the status?" Authenticate by reference number or address, read the current work-order status from the system, offer to text a status update.

Damage Claims (Vehicle Damaged by Pothole)

Structured intake of vehicle damage claim - location, time, vehicle info, contact - routed to the city's risk management or insurance contact. Distinct from a repair report.

Duplicate Reports (Same Pothole, Different Resident)

The AI recognizes the duplicate, references the existing report, offers to add the caller as a follow-up contact. No new ticket; one less crew dispatch dispute.

Cross-Jurisdiction Reports (State Highway, County Road, Private)

The AI identifies that the location is not on a city-maintained street and warm-transfers to the right authority (state DOT, county public works, or tells the caller the responsibility belongs to the property owner for private roads).

Related Road-Condition Reports

"There's a downed branch in the middle of the road." "The painted lines are completely faded." "The stop sign is leaning at a weird angle and might fall." Adjacent road-condition reports flow through the same workflow with appropriate work-order categories.

Pothole Damage to Cyclists or Pedestrians

Higher-priority intake (potential safety issue) with escalation to the city's safety coordinator.

Repeat-Failure Reports ("You Already Fixed This One, It's Back")

The AI references the prior work order, flags the repair as failed, and routes to engineering for repair-method review rather than treating it as a routine new pothole.

Calls That Should Always Transfer to a Human

Active hazardous conditions (someone is stuck, an accident just happened). Damage claims that mention attorney involvement or significant injury. Repeat callers expressing frustration with prior service. Any caller who asks for a human at any point. The AI defaults to transfer rather than handle.

The Jurisdiction Problem: City vs State vs Private

The single most common source of wasted crew time on pothole reports is jurisdiction confusion. A typical mid-size city receives a substantial share of pothole reports for roads it does not maintain - state highways running through city limits, county roads at the city edge, private drives in apartment complexes and shopping centers. Without GIS-aware routing, those reports get filed, dispatched, driven to, and then voided when the crew arrives and realizes the city does not own the road. The crew time is gone; the resident's pothole is still there.

AI pothole reporting solves this at intake. Every reported location is validated in real time against the city's GIS road inventory layer. The query returns the maintaining authority for that specific stretch of road. Three outcomes follow:

• City-maintained street. Standard workflow - file work order into the city's system, dispatch.
• State highway. The AI reads back the correct authority ("That stretch of Route 23 is maintained by PennDOT, not the city") and either warm-transfers to the state DOT pothole-reporting line or, for states with web-only intake, texts the resident the DOT report link directly. The city's work-order system records the cross-jurisdiction routing for the audit trail but does not generate crew work.
• Private road or parking lot. The AI explains the responsibility belongs to the property owner ("That address is in a shopping center parking lot, which is maintained by the property owner - here's the property management contact if I can find it"). No work order is created.

For ambiguous jurisdiction cases (city street that the state inspects, federal road on military property, contested boundary roads), the AI defaults to filing the city work order with a jurisdiction-review flag for the dispatcher to confirm before dispatch.

For most cities, the GIS-aware routing alone reduces wasted-dispatch volume by 15 to 30% within the first quarter of deployment. That recovered crew time goes to potholes the city actually owns.

Integration with 311 and Work-Order Platforms

AI pothole reporting integrates at two layers: the 311/CRM platform that owns the report record, and the work-order platform that drives the actual repair. Most cities run different systems at each layer; the AI integrates with both.

311 / CRM Platforms (where the report lives)

• SeeClickFix (CivicPlus). The most widely deployed 311-style reporting platform in U.S. cities. Native two-way integration. Reports created by the AI appear in SeeClickFix with the same fields and routing the existing intake produces.
• PublicStuff. Common with mid-size cities using PublicStuff as their 311 layer. Native integration.
• Salesforce Public Sector. Cities running Salesforce as their 311 / constituent service platform. Native API integration.
• Microsoft Dynamics 365 Government / Public Sector. Cities on Microsoft government cloud. Native integration.
• Granicus 311. Cities running Granicus as their 311 layer.
• Qscend. Common with mid-size cities for 311 reporting.
• Accela 311. Cities running Accela's 311 module alongside their permitting deployment.
• RouteSmart / Tolemi / OpenGov 311. Common in mid-size and smaller cities.

Work-Order Platforms (where the repair happens)

• Cityworks (Trimble). The most widely deployed municipal work-order platform. Pothole work orders write directly into Cityworks with asset linking against the road inventory.
• Cartegraph (OpenGov). Native integration for work-order creation, crew routing, and asset references.
• Lucity. Common with cities running Lucity for public works asset management.
• IBM Maximo. Larger cities running Maximo across multiple public works domains.
• Tyler Munis Work Orders. Cities running Tyler Munis ERP with the work-order module.
• RouteSmart, Routeware. Where the city uses specialized routing software for crew dispatch.

GIS and Address Validation

Esri ArcGIS Online and ArcGIS Enterprise for the authoritative road inventory, jurisdiction boundary, and address validation. Real-time GIS query is what enables the jurisdiction-aware routing described above.

For systems we haven't worked with yet, the AI integrates via REST API, webhook, or structured file exchange. We have not encountered a 311 or work-order platform we could not integrate with given a willing vendor and a published API.

Liability and the Audit Trail

Pothole reporting has a unique liability footprint among city call categories: cities get sued by residents whose vehicles were damaged by potholes the city allegedly knew about and failed to repair. The legal posture in most jurisdictions hinges on the city's actual or constructive notice - whether the city had been told about the pothole, when, and what the city did about it. The audit trail of pothole reports is therefore evidence in any subsequent damage claim or lawsuit.

AI pothole reporting strengthens the liability defense by producing a complete, time-stamped, audit-defensible record of every report. The record includes:

• The call recording and transcript. What the caller said, what the AI captured, every system action.
• Structured intake fields. Location, severity classification, photos, the caller's contact information.
• GIS validation log. What the AI queried, what the jurisdiction layer returned, why the report was routed where it was.
• Duplicate-detection log. Whether the AI detected an existing report; the existing report's reference and status.
• Work-order creation timestamp. When the work order landed in the city's system; the routing rule that applied; the assigned crew or queue.
• Resident notification log. SMS confirmations sent; status updates delivered; the resident's acknowledgment of the report reference.

Combined with the work-order platform's record of dispatch and repair, the AI-side audit trail gives the city attorney the timeline they need to defend a damage claim - or, where the city failed to respond within its published SLA, to assess the claim honestly and settle quickly.

For cities subject to public-records laws, the audit trail is exportable in the formats the state requires for FOIA / open-records responses.

ROI for Public Works Pothole Operations

The financial case is built on four numbers: dispatcher hours reclaimed from intake and triage, crew hours reclaimed from wasted-dispatch trips to misrouted potholes, the value of duplicate-report deduplication, and the reduced liability exposure from cleaner audit trails.

For a mid-size city handling 4,000 pothole reports per year, the typical labor cost of intake and triage runs $40,000 to $80,000 annually. The wasted-dispatch crew time on misrouted potholes runs another $20,000 to $60,000 depending on geography. Duplicate-ticket processing adds another $10,000 to $20,000. AI deployment that absorbs the intake, validates jurisdiction at intake, and deduplicates on the call typically returns 70-80% of that cost to the operating budget - and the recovered crew time is real crew time available for actual repair work.

The number that usually matters most to the public works director is not the cost line - it is the storm-season survivability. Pothole volume triples or quadruples in a two-week window after a hard freeze-thaw cycle. The legacy phone channel collapses every year. AI absorbs the surge without staffing changes, which means the constituents who experienced damage during the storm get their reports captured and tracked instead of disappearing into voicemail.

Procurement Paths That Skip the RFP

The biggest objection from city procurement officers is that AI procurement will require a full competitive solicitation that takes a year and burns through political momentum. It does not have to. Cities have multiple procurement paths that get a pilot live in 30 to 60 days.

• Cooperative purchasing. Sourcewell, NASPO ValuePoint, OMNIA Partners, BuyBoard, and TIPS-USA let cities piggyback on competitively bid contracts that other governments have already awarded.
• State master contracts. Texas cities and political subdivisions can procure BetaQuick through partner contract Texas DIR DIR-CPO-6057, which is held by BetaQuick's partner Compass Solutions, LLC. The partner-held vehicle is active through October 2030.
• Cloud marketplaces. AWS Marketplace and Azure Marketplace cover procurement procedurally for cities running on those cloud agreements.
• Direct purchase order. Pilots under the city's competitive threshold (typically $50,000 to $100,000, varies by jurisdiction) can be procured by direct PO. A first-year pothole-reporting pilot often fits inside that ceiling.
• Sole-source or piggyback on another city's contract. Some procurement codes allow piggybacking on another city's competitively awarded contract.
• Full RFP. Available if a competitive procurement is preferred or required. We routinely respond to RFPs and bring complete documentation packages.

How to Deploy in 30 to 60 Days

City pothole-reporting deployments follow a structured rollout. Because the workflow is well-scoped and the integration list is short, the timeline is typically 30 to 60 days from kickoff to live.

Weeks 1 to 2: Discovery and GIS Mapping

We sit with the public works director, the 311 / dispatcher supervisor, and the GIS administrator. We map the pothole call volume by season, document the city's severity-to-response-window rules, capture the duplicate-detection radius and time window, and confirm GIS access to the road inventory and jurisdiction layer. We identify the 311/CRM platform and work-order platform we'll be writing to.

Weeks 3 to 4: Configuration and Integration

Morgan is configured with the city's specific intake taxonomy, severity classification rules, photo-upload workflow, duplicate-detection logic, and jurisdiction-routing decision tree. Connections to SeeClickFix, PublicStuff, Cityworks, Cartegraph, Lucity, or whichever platforms the city runs are tested in sandbox. Esri ArcGIS integration is tested end-to-end against the city's road inventory.

Weeks 5 to 6: Internal Testing and Dispatcher Training

The 311 dispatch team and the public works supervisor test Morgan against realistic call scenarios across every report type, including edge cases (cross-jurisdiction, duplicates, damage claims). The supervisor is trained on the monitoring dashboard, call review, and escalation queue.

Weeks 7 to 8: Soft Launch

Morgan goes live on a defined slice of call volume - typically after-hours and weekend pothole calls first, then daytime overflow. Call quality, work-order completeness, and resident feedback are monitored daily for the first two weeks. The city retains the ability to disable any specific routing rule at any time.

Beyond Day 60: Expansion to Adjacent Public Works Workflows

Once pothole reporting is stable, the same AI infrastructure extends to adjacent 311 and public works workflows - streetlight outages, sidewalk damage, sign reports, illegal dumping, graffiti, abandoned vehicles, sewer reports, snow event surge. Each adjacent workflow reduces the per-workflow cost of the deployment.

Frequently Asked Questions