One resident, three portals, three logins
Picture a Monday morning in Bourne or Market Deeping. A resident has three things on their list: check why their rent account shows an arrears notice, update their council tax record after a household change, and submit an objection to a planning application on their street. All three are legitimate, routine tasks. All three are available online through South Kesteven District Council's digital services. And all three send that resident to a different portal.
The Housing Payment Self Service Portal, the Council Tax Self Service Portal, and the planning comment system are separate environments — different interfaces, different credentials, different conventions for what counts as a valid entry. The Pay It gateway adds a fourth address if a payment needs processing directly. None of these systems shares a common sign-in.
This is not a contrived edge case. Rent queries, council tax changes, and planning activity on nearby streets overlap often enough in a district of 365 square miles that the combination describes an entirely ordinary week for a homeowner in a contested area.
The council's digital front door, in other words, is not one door. It is a corridor of doors, each requiring a different key. The obvious question is: why were they built that way — and does that structure actually matter to the people using them?
How SKDC's portals are organised — and why
Behind each of SKDC's portals sits a different back-office system, managed by a different team. The Council Tax and Benefits Self Service Portal connects to revenues and benefits administration; the Housing Payment portal serves the housing department's rent and account records; the Pay It gateway handles general payment processing; and planning search and comment runs through SKDC's own local system — sitting alongside, but entirely separate from, the national Planning Portal used for application submission. Each environment reflects the organisational unit responsible for it.
This is not an SKDC anomaly. It is the standard architecture of UK local government digital services, shaped by decades of department-by-department procurement: councils bought or built systems to solve specific back-office problems — automating a billing cycle, digitising a register — without a shared front-end layer to unify the resident experience. The result is administratively legible (each department knows where its data lives and who owns it) but experientially opaque to someone who simply needs to sort out their household affairs in a single session.
The gap matters because residents do not organise their lives around council departments. A change of address touches council tax, housing, and benefits simultaneously. A planning objection rarely sits in isolation from other queries that week. The departmental grouping that makes perfect sense on an org chart creates navigational friction the moment a real person opens a browser — particularly in a district where, for many, picking up the phone remains a quicker and more familiar alternative.
What people actually type into the search bar
Search data does not lie about what people want. The related queries clustering around SKDC's digital services — 'council tax login', 'pay council tax', 'rent balance', 'bin collection postcode' — are short, specific, and transactional. Nobody types 'South Kesteven self-service portal suite'. They type the task.
This is not incidental. Nielsen Norman Group's research on mental models identifies a pattern sometimes called Jakob's Law: users spend most of their time on websites other than the one they are currently visiting, and they arrive with expectations built from those other experiences. Online banking and retail have spent years optimising for task completion — search for what you want, go directly there. When a council portal instead presents a menu of departmental categories, it is speaking a language residents were never taught.
The mismatch produces a predictable sequence. A resident searching 'rent balance' lands on a page that requires them to identify which of several portal environments handles housing payments, register or recall credentials specific to that system, and navigate an interface structured around the department rather than the question they brought with them. At each step, the gap between what they expected and what they found costs effort. Most people will absorb some of that friction. A significant number will not.
A resident who abandons a digital task has not abandoned the task itself. They have shifted it to a more expensive channel — typically a phone call that costs the council several times more to handle than an equivalent self-service transaction. Channel shift strategies exist precisely to prevent this outcome. Portals organised around departmental logic, rather than resident intent, tend to generate the very phone contacts those strategies aim to retire.
The search terms, in this sense, are not just a curiosity about how people use Google. They are a map of the gap.
Three moments where the interface breaks from resident reality
Three specific SKDC design decisions each create friction of a different kind — and each one reveals a different mismatch between what the portal assumes and who is likely to arrive at it.
Assumption-based: the email security key
The Self Service Portal's recently added one-time security key is delivered by email at each sign-in. The security rationale is sound. The assumption embedded in it is less certain: that the resident has a functioning email account, can access it promptly on the same or a second device, and is comfortable switching applications mid-task. Across a 365-square-mile rural district with older demographic profiles and variable connectivity, that combination does not reliably hold — which means the added security step is also, for some residents, an additional reason to ring instead.
Disclosure-based: the five-day payment lag
The Pay It portal carries a banner stating that payments made in the last five days may not yet appear on the account. The transparency is genuine — the limitation is stated before a resident looks for their payment. But disclosing a gap is not the same as closing it. A resident who has just paid a council tax bill and cannot see confirmation on screen has a rational basis for concern. The banner explains the delay; it does not resolve the uncertainty that may send them back to the phone line.
Privacy-risk-based: the planning comment register
Commenting on a planning application through SKDC's online system means accepting that your full name and address will appear unredacted on the public planning register — a statutory requirement under the Town and Country Planning (Development Management Procedure) (England) Order 2015. The council correctly states this obligation. What the design cannot easily resolve is the decision it creates: a resident on a contested street must weigh that personal exposure before choosing the online route, and the phone number displayed on the same page carries no equivalent visibility burden.
The shared pattern is that each friction point has a legitimate origin — security policy, system constraint, statute. That legitimacy is part of what makes redesigning around it genuinely difficult. In each case, the assumed user arrives informed, technically equipped, and comfortable with the trade-off being asked of them. That describes many residents. It does not describe all of them.
Rural South Kesteven as the overlooked variable
South Kesteven spans 365 square miles — a district large enough to contain Grantham's town centre, Stamford's Georgian streets, and dozens of villages connected by single-carriageway roads and variable broadband. That geography is not incidental to the portal design question; it is the question.
SKDC does not currently operate a standalone digital inclusion strategy for its own district. Residents who struggle online are directed to Lincs Digital, a county-wide initiative, NHS digital coaching programmes, and the national Project Gigabit broadband rollout. What is absent is a layer of local calibration: district-specific data identifying which communities lack reliable connectivity, which age groups are least digitally confident, and where digital-first service design is most likely to produce exclusion rather than convenience. That layer is not publicly visible in SKDC's portal documentation.
County-level data offers a partial signal. The Lincolnshire Visual Intelligence System's Digital Exclusion theme maps households below the 10Mbit/s decent-broadband threshold and identifies pockets of high potential deprivation across the county — though the published data specifically names East Lindsey as a notably affected area, not South Kesteven. Whether comparable concentrations exist within South Kesteven's rural parishes is not addressed at district level, which is precisely the problem: absence of local data is not evidence of absence.
Rural residents are not an edge case in a district of this character — they are a substantial portion of the population the portals are built to serve. Designing digital-first without local calibration is not a neutral choice. When the assumptions embedded in a service — reliable email access, a stable connection, sufficient device confidence — do not hold, the cost of that mismatch falls on the resident. They reach for the phone. The council logs a channel-shift failure. The cause stays unexamined.
What resident-centred council design actually requires
Good digital public service design has a clear benchmark in the UK: the Government Design Principles published by GDS. Three of its eleven points are particularly direct. Services must start with user needs identified through research and data, not assumptions. Analytics must be built into every service, always on and easy to read. And teams must do the hard work to make things simple — explicitly rejecting the position that legacy complexity is a legitimate justification for user difficulty.
Against those criteria, what SKDC's public portal pages do not show is significant. There is no publicly visible evidence of resident-journey mapping, embedded analytics reporting, or user-testing documentation across any of the four portal environments. That absence does not prove such work has never happened internally; it does mean the evidence base for design decisions is not visible to the people affected by them.
Councils that have moved residents successfully toward digital channels share a recognisable toolkit: single sign-on, pre-populated forms drawing on data the council already holds, proactive support for residents with lower digital confidence, and iterative redesign driven by drop-off and abandonment data. None of this is technically exotic. It is friction-reduction applied in sequence and sustained over time.
The deeper problem is structural. SKDC's portals were built around the council's internal departmental organisation — Council Tax, Benefits, Payments, Planning — and continue to operate that way. That architecture is coherent from the inside. From the resident's position, it requires navigating a directory of departments at the moment they most need a single answer.
The planning comment system is a useful point of reference here not because its frictions are unique but because they resist surface-level redesign: statute, departmental separation, and the absence of integrated identity each constrain the experience from a different direction simultaneously. Updating the interface cannot resolve those layers.
For South Kesteven specifically — a rural district without district-level digital exclusion data or a shared identity layer across its services — the gap between current design and resident-centred design is not primarily a technical one. It is an organisational question about whose reality the next iteration of the portal is being built around, and whether the council is yet looking at the evidence needed to answer it.
- [1] South Kesteven. https://en.wikipedia.org/?curid=426477 https://en.wikipedia.org/?curid=426477