Digital one-stop shop: what it centralizes, and what it does not
The one-stop shop promises to bring it all together. In practice, it centralizes how requests come in, not how they are processed, and that is good news.
The term has become a must in modernization projects. A digital one-stop shop, and residents have only one place to turn to. The promise is sound, but it is often misunderstood, which leads to oversized projects and disappointment at launch.
The short answer: a one-stop shop centralizes the intake and tracking of requests. It does not centralize their processing, which stays within departments and their specialized tools. Confusing the two leads to wanting to replace a municipality’s entire information system, which almost never succeeds.
What it really centralizes
A front door. Whatever channel residents use, their request arrives in the same place, in the same format, and becomes visible to the department concerned. That alone is considerable: in many municipalities today, the same request can arrive by phone, by e-mail, through a form on the website and at the counter, without any of these channels talking to each other.
It also centralizes tracking. Knowing where a request stands, who is handling it, what has already been answered. That is what allows staff to answer a resident who calls back, without having to dig an e-mail out of a shared inbox.
What it does not centralize, and that is a good thing
Specialized processing. A civil registry document is drawn up in the civil registry software, a planning permission is processed in the planning software. These programs carry rules, checks and obligations that a general-purpose one-stop shop is not meant to take over.
Trying to absorb them turns a six-month project into a multi-year undertaking. Citizen relationship management sits alongside these tools, not in their place.
The black box risk
A poorly designed one-stop shop can produce the opposite of what was expected. Residents submit their request, receive nothing more than an acknowledgment, and call back two weeks later to find out where it stands. The calls you wanted to eliminate come back, with a sense of opacity on top.
The remedy comes down to a few things: a clear progress status, an estimated timeframe when possible, and a notification at every step that matters. A request that visibly moves forward does not generate a call.
Rolling out, one request type at a time
Opening every request type on the same day exposes you to a simple difficulty: if something goes wrong, nobody knows what to fix first. A rollout in waves, starting with the highest-volume and best-defined request types, gives the team time to adjust.
Each wave teaches something about how to word questions, which documents to ask for and what special cases arise. The digital one-stop shop is built through this back-and-forth, not through specifications written in one go.
What to decide before starting
Who answers. A one-stop shop makes requests visible; it does not decide in the local authority’s place who handles what, or within what timeframe. These rules are set before opening, otherwise they will be set in a rush, in view of the first requests piling up.
