Most software RFPs ask vendors to confirm what their product does. Two hundred rows: does the system support configurable workflows, yes; does it integrate with GIS, yes; does it provide role-based permissions, yes. Every vendor scores 95 percent, the checklist decides nothing, and the project's real risks never come up. One question does more work than the whole matrix.
The Question
Describe, specifically, how your system and your team handle things going wrong: an exception your workflow doesn't fit, a migration record that fails, a staff member who disagrees with the system, and a change we request after go-live. Four scenarios, one question, and none of them can be answered with yes. Feature lists describe the product on its best day; projects fail on the other days, and every implementation hits all four of these. The vendor's plan for those moments is the product you're actually buying. The demo is the brochure.
What the Four Scenarios Look Like in a Real Office
The exception. A permit application is complete — fees paid, plans approved, one inspection left — and the applicant dies. The estate wants to transfer it. There is no Transfer Applicant button, no status between Active and Withdrawn, and the permit tech has to put the truth somewhere. If the choices are overwriting the applicant field or keeping the real story in a sticky note, the system has already lost.
The migration failure. The import runs and 400 records bounce because the old system allowed blank required fields — permits with no parcel number, inspections with no inspector name. The record counts matched; the identities didn't. Somebody has to own that queue: which records, reviewed by whom, resolved by when, and what happens to the ones nobody can reconstruct because the clerk who knew is retired.
The staff disagreement. An inspector looks at a failed verdict the system generated from a checklist rule and knows it's wrong — the condition it flagged was corrected on site an hour earlier. He needs to override it, on the record, with his name and reason attached, without calling the vendor's support line. If the only way to clear it is editing the underlying data until the rule stops firing, staff will learn to route around the system within a month.
The post-go-live change. Council adopts a new fee schedule effective July 1. The fees were hardcoded in March, during implementation, by a consultant who has since rolled off the project. Is the update a configuration screen the billing clerk can use, a change order, or a six-week ticket? One of those answers is true. Get it in writing before you sign.
Reading the Answers
Strong answers sound specific and slightly boring. "Exceptions get a Held status with a required reason field, and they appear as their own line in the monthly compliance report." "Failed migration records land in an error queue; our data lead works it with your records officer, and anything unresolved at go-live goes on a punch list you sign off." "Overrides are a permission, and the audit trail shows who, when, and why — here's the screen." "Fee schedules are effective-dated configuration your staff maintain; we'll show you where."
Weak answers route everything back to the happy path. "Our workflows are fully configurable." "Our migration tools are robust — that rarely happens." It always happens. A vendor who says otherwise hasn't done many implementations, or isn't describing them honestly.
Make It Scoreable
Put the question in the RFP and weight it like price. Then carry it into the demo: don't let vendors describe exception handling, make them show it — the dead applicant's permit, the inspector's override with the audit trail on screen, the fee change made live by someone who isn't the sales engineer. The gap between described and shown is where bad projects hide.
Any vendor can answer what the product does. The ones worth hiring can answer what happens when it doesn't — with statuses, screens, and a straight face. Ask the question. The answers sort the field faster than any checklist.