When the service request app goes offline, where does the pothole go?
Columbia, South Carolina took its resident app offline after a ransomware attack and gave people a phone number instead. That's the right first move. The harder questions come next, and every city should answer them before it's their turn.
When a city's 311 or service request app goes offline, residents need one published fallback right away, like the phone line Columbia, South Carolina announced after its October 2026 ransomware attack. Then someone has to log each call the same way, keep a record outside the affected system, and load every request back in once the app returns, so nothing is lost in between.
What happened in Columbia
On October 20, 2026, the City of Columbia, South Carolina found suspicious activity on its network and called the South Carolina Law Enforcement Division. Three days later the city confirmed it was a ransomware attack. Affected applications were taken offline as a precaution while investigators and outside specialists work out what was touched.
The resident-facing casualties, per the city's October 23 update, include MyColaSC, the app people use to report problems, plus online services for Animal Services, Parks and Recreation reservations and the city's mapping system. The October 21 notice also listed business licensing and planning services. Police, fire, 911, Columbia Water and the Payment Center, including online payments, kept running. The city says business continuity measures are in place across affected departments. WIS reported on October 23 that there was no timeline yet for restoring the affected services.
For the reports MyColaSC normally takes, like potholes, fallen trees, broken park equipment and streetlights, the city published one instruction: call (803) 545-3300.
That's a good, clear first move. One number, said the same way in every release and news story. We're not going to guess at what Columbia's teams are doing behind it. The point is what any city or county should ask itself, today, about the same situation. These are questions to work through at a table with the people who'd actually be on the phones, before you need the answers.
Questions about the first day
Who announces the fallback, and where? If your resident app goes dark, which number or address do you publish? Does it reach people on the app itself, the website, social accounts and local news at once? If the website runs on the same systems, where do you post?
Is the number staffed for the volume? A phone line that usually takes a handful of calls an hour may suddenly get everything the app used to absorb. Who answers, during what hours, and what happens after hours?
What does the person on the phone write down? Decide the minimum fields before the call comes in: what the problem is, where exactly, when it was reported, how to reach the resident, and whether it's urgent. If ten people take calls ten ways, you'll spend weeks cleaning it up.
What's urgent, and who decides? A downed tree across a road isn't the same as a faded crosswalk. Callers need a simple rule for what gets passed to a crew immediately and what waits in the log.
What do you say when you don't know the end date? Columbia's coverage noted there was no restoration timeline yet, which is normal early in an investigation. Decide in advance how often you'll post updates even when nothing has changed, and who signs off on them. Residents tolerate "we don't know yet" far better than silence.
Who can authorize spending on the fallback? Extra phone staff, overtime for crews working from paper, a temporary form tool. Know who approves it so the first afternoon isn't spent finding out.
A phone number is a fallback for residents. A paper log nobody reconciles is a second outage that starts the day the app comes back.
Questions about the weeks in between
Where does the log live? It should not live on anything connected to the systems under investigation. A shared spreadsheet on an unaffected account, a standalone form, even numbered paper forms can work, as long as everyone uses the same one.
How do crews get work? If dispatchers usually pull jobs from the request system, how do they get the day's list now? Who prints it, who marks it done, and how does done get recorded?
What do you tell residents who ask about an old request? Requests submitted before the outage may be unreachable for a while. Have a plain, honest answer ready, and a way to take the details again without making people feel like they're starting over.
Which other services share the problem? In Columbia's case the list ran from animal services to park reservations to mapping. Each one needs its own answer for how people get help until the system returns. For why stalled systems flood the phones, see why "where is my application?" calls are a status problem.
Can staff do their basic jobs? WIS quoted an anonymous city employee saying staff couldn't clock in and out. That's one person's account, but the question is fair for every city: which internal tools, like time sheets, purchasing or permits, would also need a manual fallback?
How the work moves
A request's path while the app is down
- Resident calls
One published number replaces the app.
- Call taker logs it
Same fields every time, in a log outside affected systems.
- Urgency rule
Hazards go straight to a crew; the rest wait in the log.
- Crew works from a list
Printed or shared daily; completion recorded.
- Restore day
Each entry loaded with its original report date.
Questions about the day the app comes back
This is the step most plans skip. A phone number is a fallback for residents. A paper log nobody reconciles is a second outage that starts the day the app comes back.
Who loads the log into the system? Every request taken by phone needs to end up in the restored system with its original report date, not the date someone typed it in. Otherwise your response-time reporting quietly lies for months.
How do you avoid duplicates? Some residents will call and then submit the same report through the app once it returns. Decide how you match them, usually by location and problem type.
What happens to requests that were already open? Check whether work orders open before the outage are still accurate. Some may have been completed by crews working from paper, and nobody updated the record.
What do you tell residents? A short public note when the app is back, saying what was carried over, is worth more than silence.
Decision guide
Day one versus restore day
| Consideration | First day questions | Restore day questions |
|---|---|---|
| Residents | Where do we tell them to go? | What do we tell them was carried over? |
| Records | What does every call taker write down? | Who loads the log, with original dates? |
| Crews | How do they get today's jobs? | Which open orders were already done? |
| Duplicates | Not yet a problem. | How do we match phone and app reports? |
What to have ready before you need it
Most of these answers fit on one page per service. Write the fallback number and who staffs it. Write the fields every call taker records. Write where the log lives and who owns it. Write the urgency rule. Write who reconciles the log afterward and how.
Then run it as a short tabletop: pick a Tuesday morning, say the resident app is down, and walk through the first hour, the first week and the restore day. You'll find gaps fast, usually in the handoff between the people taking calls and the crews doing the work.
Our government and public sector work is mostly building the systems residents use and the staff screens behind them. Designing the fallback and the way back in is part of that job. If you want help writing yours, talk to us.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.