Survey results in one file, everything else in twenty
Your perception survey is run by a research company or in-house. Results come back as a spreadsheet of responses. The management information measures, such as repairs completed on time or complaints responded to within timescales, come from housing management, repairs and complaints systems. Someone in the performance team spends weeks combining them, checking definitions and building charts for the board.
Then the board asks why satisfaction with repairs is lower in one area, and nobody can answer without going back to the raw data.
Why the numbers are hard to assemble
The survey and the operational systems describe the same homes and tenants but do not share identifiers in a clean way. Definitions of measures need care. And the useful question, what drives dissatisfaction here, needs joining survey answers to what actually happened to that household.
- Survey responses are keyed by a reference the research company created.
- Operational measures come from several systems with their own property references.
- Definitions are applied in spreadsheets, differently each year.
- Sample checks, such as coverage by area and tenure, are done by hand.
- Free-text comments are read by one person, if at all.
What slow, shallow reporting costs
Results arrive too late to change anything this year. Board discussions stay at headline level because nobody can drill down. Tenants who took the time to explain what went wrong see no change. And the performance team spends its skills on copying and pasting rather than analysis.
The data pipeline we build
- Survey returns are loaded from your research provider's export or survey tool, with the property or tenancy reference they hold.
- Operational data is read from your housing management, repairs and complaints systems through their APIs or reporting databases.
- Properties are matched across sources using your property reference, with unmatched records listed for a person to fix.
- Your definitions for each measure are written down once and applied in code, so they are the same every year and can be checked.
- Sample coverage by area, tenure and property type is shown next to results, so the board can see how representative they are.
- Free-text comments are grouped into themes, such as repairs communication or anti-social behaviour, using a language model, with a person checking the themes and examples.
- Results are shown in dashboards, for example in Power BI, with drill-down to area and service, and a link between each dissatisfied response and what happened to that home, for staff allowed to see it.
| Question | Before | With the pipeline |
|---|---|---|
| What are this year's results? | Weeks of work | Loaded when the survey closes |
| Are definitions consistent? | Depends on who built it | Written once, applied in code |
| Why is one area lower? | Go back to the raw data | Drill down on screen |
| What do comments say? | Read by one person | Themed, with examples |
| How representative is it? | Checked by hand | Coverage shown with results |
How you run your survey and what you report are decisions for you and your advisers. The pipeline prepares and presents the data; it does not decide what you submit.
What the performance team can do now
Reports are ready soon after the survey closes. Board discussions can move from headline to cause. Service managers see results for their own area alongside their operational figures, so they can act on them. And comments tenants wrote are actually read, in themes, with examples.
Is this how your satisfaction reporting works?
- Combining survey results and operational data takes weeks.
- Definitions are applied differently each year.
- You cannot quickly explain differences between areas.
- Free-text comments are barely used.
- The performance team is stuck on data preparation rather than analysis.