Development Agency
Contact Sign in Get a project quote

Service

Resident request system development

For service managers and digital leads at councils, housing providers and estate management teams who need resident requests captured once, categorised, placed on a map, routed to the right team or contractor and tracked to closure against targets the organisation sets itself.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A housing provider with a few thousand homes receives requests all day and from every direction: a phone call about a dripping overflow, an email with three photographs of fly-tipping behind the bin store, a message through a social media page about a streetlight, a letter about noise from the flat above, a visit to the office about a broken gate.

  • Each is written up by whoever took it, in whichever system they had open, and passed on by email to the repairs team, the estates team, the tenancy officer or the contractor.
  • The same fly-tip is reported by four residents on four days and raised four times; the contractor attends the first, and the other three residents are told nothing.

Where it gets harder

A request has no single status.

  • The customer services team says it has been passed to repairs; the repairs team says it is with the contractor; the contractor says it was done on Tuesday; the resident says nobody came.
  • Targets exist, written in a service standard, but nobody can say which open requests are past their target date this week without building a spreadsheet from three exports.
  • A noise complaint that should have gone to the tenancy team as anti-social behaviour sits in the repairs queue for a fortnight because the form had one free-text box.
  • Site visits are arranged by phone and missed because the resident was out, and there is no record of the appointment to show the visit was offered.
  • At the quarterly meeting the service manager is asked for performance against targets by category and area and cannot give a figure she would stand behind.

Scope of the service

What the build covers

A custom resident request build normally covers:

  • Request categories with their own tailored forms So that a repair asks about access and the fault, an environmental report asks for a location and photographs, an anti-social behaviour report asks about dates, times and whether the resident wants contact, and a general enquiry asks for little
  • A location picker that places each request on a map against an address A block, a communal area or a point on the street
  • Service levels per category With target dates calculated when the request is logged, held as the organisation's own targets
  • Triage and routing rules that assign each category or area to a team An officer or a contractor, with manual reassignment and a reason
  • Duplicate detection That shows existing open requests near the location before a new one is logged and lets staff link reports to one case while keeping every reporter informed
  • Site visit scheduling With appointment slots offered to the resident and recorded
  • Status updates sent to residents By email or text at the stages the organisation defines
  • A resident portal showing their open and past requests
  • Performance reports against targets by category Team, contractor and area

How discovery works

Discovery walks through a week of requests with the service manager and the team leads: which categories exist, which questions each really needs, how requests reach each team today, which targets apply, which contractors need their own login, what residents must be told and when, and what the quarterly report must show. Each becomes a named stage in the scope document: submit, triage, assign, visit, update, close, report.

Deliberately out of scope

  • The repairs scheduling and stock system a housing provider's contractor already runs, which receives jobs from the request system and returns completion data
  • Tenancy case management beyond logging an anti-social behaviour report and routing it
  • Any claim that targets will be met. The system calculates target dates from your service levels and reports against them
  • Meeting them is the organisation's work

When the scope grows

Scoping scenario

A district council with eleven categories, six internal teams, four contractors with their own logins, a resident portal and a map of the whole district is a different build from an estate management team with three categories, one contractor and a hundred requests a month, and the scope document says so plainly.

Deliverables

What you receive

  • Discovery notes from a walk-through of a week of requests, including the current forms, inboxes, service standards and the last quarterly report
  • A written scope document naming each stage from submission to reporting, the category forms, the routing rules and what is excluded
  • Design of the public request form with map pin, the triage queue, the team view and the resident portal on phone and desktop, in plain language and checked against WCAG 2.2 AA as a target
  • The build, deployed to your hosting or ours
  • Migration of open requests and the last year of closed ones from your current system or spreadsheets, where relevant
  • Category forms, service levels, routing rules and status message templates configured and tested with each team
  • Training for customer services, team officers, contractors and the service manager, with a short written guide
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current forms and inboxes, the service standards, the team and contractor list and the map data you hold; the service manager and a team lead named as contacts.

    Project stage: Onboarding

  2. Planning

    Discovery with the service manager, customer services and each team lead; categories, targets, routing and the scope document are agreed with milestones.

    Project stage: Planning

  3. Design

    Clickable designs of the request form with its map pin, the duplicate prompt, the triage queue, a team officer's list and the resident portal, reviewed with residents the organisation invites.

    Project stage: Design

  4. Development

    Built in stages: categories, forms and locations first, then triage, routing and duplicates, then visits, status updates, the portal and reports.

    Project stage: Development

  5. Client review

    Customer services and two teams run a shadow fortnight, logging real requests alongside the old process and telling us where routing, targets or messages differ from practice.

    Project stage: Client review

  6. Revisions

    Form questions, routing rules, duplicate radius, visit slots and message wording are adjusted from the review and re-checked against the scope document.

    Project stage: Revisions

  7. Ready for launch

    Open requests migrated, contractor logins issued, status messages tested on numbers and addresses you control, the public form linked from your site, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    New requests arrive through the system from launch day; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Email and SMS providers for status updates, visit confirmations and reminders
  • Mapping and address lookup services for the location picker and area boundaries
  • Contractor job-management and repairs scheduling systems that receive jobs and return completion data
  • Housing management and tenancy systems supplying the property and tenant register
  • Customer contact centre telephony that opens a request from a call record
  • Asset registers for streetlights, bins, play equipment and communal assets
  • Document and photo storage for evidence attached to a request
  • Business intelligence tools receiving the performance data as a periodic export

How we would approach it

Worked example

Concept demo

A housing provider with six teams and four contractors

The situation

A housing provider managing several thousand homes took requests by phone, email, social media and at the counter, wrote them into three systems and could not report against its own service standard without a hand-built spreadsheet.

Why it is a custom build

The reason this needs a custom build rather than a generic ticketing tool is the routing and the register: requests had to be tied to the property and asset registers the provider already held and handed to a contractor system that returns completions, so that the status a resident sees is the real one.

The scope we would propose

  • Nine categories, each with a tailored form and a location picker tied to the property register
  • Service levels per category that calculate a target date at logging
  • Routing rules that send repairs to the contractor system, environmental reports to the estates team by area and anti-social behaviour to the tenancy team with the resident's contact preference
  • Duplicate detection showing open requests within a set distance before a new one is created, with linked reporters each informed
  • Visit slots offered by text and recorded
  • A resident portal
  • A performance report by category, team, contractor and area against the targets the provider set

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of request categories and how different their forms need to be
  • Number of teams, officers and contractors, and whether contractors work inside the system or through their own
  • Service levels per category and the reporting required against them
  • Location model: addresses, blocks, assets and area boundaries, and the mapping service used
  • Duplicate detection rules and how linked reporters are informed
  • Visit scheduling and the channels used for status updates
  • Resident portal and whether it is tied to an existing tenant login
  • Volume of open and historic requests to migrate
  • Hosting choice: your own hosting or ours

Start from a package

Resident request package

Categorised request forms with map location, duplicate detection, routing to teams and contractors, visit scheduling, resident status updates, a resident portal and reports against targets.

Custom build
View the package

FAQ

Frequently asked questions

How do you decide between a custom build and the package?

Discovery compares your categories, teams and targets with what the resident request package does through configuration. A handful of categories, teams that work inside the system and standard status messages usually fit the package. Integration with a contractor system or a housing management register, telephony that opens requests, or reporting in a prescribed format point to custom work, and we say which before anything is quoted.

Does the system commit us to response times?

No. Service levels and target dates are your own configuration, taken from your service standard, and the system calculates and reports against them. It does not set targets for you and nothing in the build promises that they will be met.

How are duplicate reports handled?

When a request is logged, staff and residents see open requests near the same location in the same category and can link the new report to the existing case. Every linked reporter receives the status updates for that case, so the fourth person to report a fly-tip is told when it was cleared.

Can contractors update requests themselves?

Yes, either through their own login, where they see assigned jobs, record attendance and completion and upload photographs, or through a connection to the job-management system they already use, which returns completion data to the request. The scope document records which applies to each contractor.

Who owns the system afterwards?

You do. Source code and data, including every request, photograph and status change, are handed over at delivery. Hosting and maintenance are optional and separately agreed, and the system can move to another provider.

Get a project quote for resident request system software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences