Facility User Feedback Planning Checklist

Write down the handful of things you would genuinely change if you knew about them, since those are the only questions worth putting to anybody.

Questions asked out of politeness produce answers nobody uses, and users notice that faster than operators expect.

Decide which parts of the experience you can influence, such as booking, access, lighting, cleanliness, storage or noise, and which are fixed by the building itself.

Asking about things that cannot change invites requests you will have to refuse, which teaches people that commenting is pointless.

Note the questions you already know the answer to, and take them out, because asking them invites the reply that nothing was done last time.

Confirming a known problem uses goodwill without producing information.

Record whether you are asking about the facility itself, the arrangements around it, or both, and keep those two things separate in the answers.

Comments about a booking process and comments about a floor need different people to read them, and mixing them buries both.

Decide what you will deliberately not ask about, and write down why, so somebody later does not add it back without knowing.

The list of what you chose not to ask is as useful to a successor as the questions themselves.

Write down who inside the organisation wants this feedback and what they intend to do with it, before designing any part of it.

Feedback with no destination accumulates and is eventually abandoned, which is worse than never having collected it.

Decide how somebody reports a broken, missing or damaged item, and keep that route separate from the one carrying opinions about the facility.

Fault reports sitting in a general comment list are read late, and the delay is entirely avoidable.

Write down what happens when a comment turns out to describe a hazard, and who it reaches straight away rather than at the next meeting.

Hazards are frequently described politely inside a general comment, which is why somebody has to be watching for them.

Anything describing a hazard or an injury is passed to suitably qualified people and, where relevant, the relevant authority rather than held in a feedback list.

Note that a comment about safety is a prompt to ask somebody qualified, not something to be weighed against other comments on the same list.

Treating a safety comment as one opinion among many is how it ends up outvoted by preferences.

Whether anything at the facility is safe or unsafe is a judgement for suitably qualified people and the relevant authority, never a matter of consensus.

Agree who reads incoming comments, and how often, so that an urgent one does not sit unopened behind a general enquiry.

The gap between a route existing and somebody watching it is where most operational surprises come from.

Record how a user is told that their report reached the right place, since silence trains people to stop reporting anything.

Acknowledgement matters more to future reporting than the outcome does.

Decide where feedback about the conduct of other users goes, and handle it separately from comments about the facility itself.

Comments about people arrive through the same box as comments about lighting, and they need a completely different route.

Matters involving conduct, welfare or the protection of children and vulnerable users are referred to the appropriate authority and suitably qualified people.

List where your users already look, such as a booking confirmation, a group message, a noticeboard by the door or the person who unlocks the gate, and place the route there.

Feedback follows existing habits, and a new channel is a new habit you would have to build first.

Decide whether comments can be left without giving a name, and note what that changes about being able to follow anything up.

Both choices are defensible, but the consequences differ and are much easier to accept when decided deliberately.

Note whether anybody would need help to comment at all, such as a user who does not read the language used on site or who does not use a phone.

The users who cannot use the route are systematically absent from the answers, and their absence is invisible.

Write down who monitors each route you open, since an unwatched route is worse than not offering one at all.

An unread channel creates a false impression that nothing is wrong, which is the opposite of what it was for.

Check that the route works for a group leader speaking for a club as well as for one person speaking for themselves.

A route designed only for individuals loses the structured comments that clubs are well placed to give.

Ask what the booking or access arrangement already collects, so you are not asking again for something you already have.

Asking users to repeat what they have already told you is the fastest way to make a feedback route feel careless.

Record what you tell people about how their comments are stored, who reads them and whether they are shared.

People answer more usefully when they know where their words go, and the statement has to be written before the route opens.

What may be collected, kept or shared about identifiable users is a question for a suitably qualified adviser and the relevant authority.

Write questions about a particular visit rather than about the facility in general, because people remember occasions and not averages.

General impressions produce agreeable answers, while a described visit produces something specific enough to look into.

Ask what happened rather than how satisfied somebody was, since a described event can be acted on and a general impression cannot.

The gap between a pleasant answer and a useful one is almost entirely in this choice of wording.

Avoid asking people to choose between options you are not actually prepared to act on, since the losing option becomes a grievance.

A choice offered and then ignored does more damage than never having asked.

Leave one open space for anything you did not think to ask about, because that is where the genuinely useful surprises appear.

Structured questions can only return what you already suspected, and the open box is where new information arrives.

Keep the whole thing short enough to complete while standing at a gate, and try it on somebody who had no part in writing it.

Length is the main reason feedback is abandoned halfway, and the author is always the worst judge of it.

Note where a question could embarrass somebody into a polite answer, such as asking about cleanliness in front of the person who cleans, and reword it.

Politeness contaminates feedback quietly, and the resulting answers look like agreement.

Note which groups you hear from constantly and which have never sent anything at all, since silence is not agreement.

A facility usually optimises around its most vocal users without anybody deciding to do that.

Write down which users have stopped coming, if the booking arrangement shows that, and consider asking them rather than only asking those still here.

People who left know exactly what is wrong and are the only group never asked about it.

Ask group leaders to pass questions on to their members rather than answering on behalf of everybody in the club.

A club leader answers about their own experience, which is rarely the same as that of a junior member or an occasional player.

Decide how a first-time visitor is asked about the things regulars stopped noticing, such as finding the entrance, the lights or the way in after dark.

Newcomers see the site as it actually is, and they only see it that way once.

Record what neighbours and passers-by say, and keep it apart from what users say, since they are answering a different question entirely.

Mixing neighbour comments with user comments makes both harder to act on and obscures who wanted what.

Consider asking somebody unfamiliar with the site to arrive, find the facility and describe what confused them on the way in.

This produces more usable information about signage and access than any question you could write.

Agree who acknowledges each comment and what they say when the answer is not yet known, since an honest holding reply keeps people engaged.

Most dissatisfaction with feedback arrangements is about the silence rather than about the decision.

Decide what happens to a complaint about a person rather than about the facility, and who handles it once it is out of the general route.

These arrive unexpectedly and are mishandled mainly because nobody had decided where they go.

Complaints involving individuals, conduct or welfare follow the appropriate local route and are referred to suitably qualified people or the relevant authority.

Write down what is done with comments nobody can act on, and say so openly rather than leaving them looking ignored.

A published no is far better received than silence, and it stops the same request arriving repeatedly.

Keep what people actually wrote rather than a summary of it, since the summary always loses the detail that made it worth reading.

Summaries are written by whoever received the comment and inevitably reflect what they already believed.

Note when several comments describe the same thing, since a pattern is evidence while a single comment is a prompt to go and look.

Separating the two protects you from redesigning something because one person mentioned it once.

Decide what is kept, for how long and who can see it, and ask where the limits on that come from rather than deciding it yourselves.

Holding comments about identifiable people brings obligations that are easier to meet if considered before collecting anything.

How personal information may be kept, seen and shared is confirmed with a suitably qualified adviser and the relevant authority.

Write down which changes came from what users said, so the connection is visible to the people who bothered to say it.

Visible cause and effect is the only thing that sustains a feedback arrangement past its first attempt.

Record the comments you decided not to act on and the reasoning behind that, since the reasoning is what protects the decision later.

Without a recorded reason, a later group reverses the decision and rediscovers the original problem.

Note which feedback raises a question for a professional rather than a change you can make, and pass it on as a question rather than as a task.

Comments about water, lighting, cracks or access are evidence for somebody qualified rather than instructions to the operator.

Comments touching on structure, drainage, electrical work, access or safety become questions for qualified professionals rather than decisions for the operator.

Decide who tells users what changed and by which route, choosing one they will actually see rather than one that suits the organisation.

Announcing a change through a channel users ignore has the same effect as not making the change at all.

Keep the feedback record where a successor can find it, since the awkward comments are the ones most likely to be quietly lost.

A feedback trail kept in one individual account goes when that individual does, and the unresolved comments are the first part to be lost.

Agree a point at which you look at the collected feedback together, rather than only reading it when something has already gone wrong.

Comments read one at a time never reveal a pattern, and the pattern is the part worth acting on.