Feedback that reaches someone while it still matters

Most feedback systems collect. This one had to deliver.

Paper forms and generic survey tools both fail hospitals the same way. They gather responses competently and then hold them until someone runs a report. By the time a complaint about a specific department on a specific afternoon reaches the person responsible for it, weeks have passed, the shift has changed, and nobody can reconstruct what happened.

That delay is not an inconvenience. It converts feedback from something actionable into something historical.

Feedback that arrives late is data. Feedback that arrives now is an intervention.

So the system was built around delivery rather than collection. A submission is stored, and in the same moment the responsible personnel receive a WhatsApp notification with access to that specific response. Nobody has to remember to check anything.

What happens when a patient presses submit

The form is only as long as the patient needs it to be

A linear questionnaire asks everyone everything. A patient whose visit went well is taken through eight questions about what went wrong, and a patient with a genuine complaint reaches the free-text box on question twenty-two, by which point many have abandoned the form.

The questionnaire engine branches instead. A yes or no answer determines what appears next, follow-up questions surface only where a response warrants them, and irrelevant sections are skipped rather than displayed and left blank.

For a patient who had a straightforward visit, that is a short form. For a patient who has something to say, the system asks more precisely — which is the only way to get detail worth acting on. Completion rate is the metric a feedback system lives or dies by, and length is the main thing that kills it.

Tamil is a data quality decision

Offering the questionnaire in Tamil as well as English is usually filed under accessibility. That undersells it. A patient answering in a second language does not simply find the form harder — they give shorter, blander, less specific answers, because articulating a complaint precisely is difficult in a language you are not fluent in.

The hospital was not short of responses. It needed responses with enough detail to act on. Letting a patient describe what happened in the language they think in changes the content of the feedback, not just the completion rate.

Feedback as audit evidence, not marketing

This system exists to serve a quality management process, which changes what it has to be good at. Marketing feedback wants volume and a favourable average. Quality management wants consistency, traceability and a record that stands up to review.

So responses are stored structurally, the questionnaire path is recorded alongside the answers, and every submission remains individually retrievable rather than being absorbed into a score. A reviewer can produce the specific response behind a specific finding, which is what an audit trail actually means.

How the team built it

GegoSoft engineers use Claude Code as standard daily tooling. The branching engine was where it mattered here — conditional questionnaire logic has a large number of paths, and testing that every combination of answers leads somewhere sensible is exactly the kind of exhaustive work that gets skipped and then surfaces as a patient hitting a dead end mid-form.

The notification-first design, the questionnaire structure and the decision to build standalone rather than inside a hospital system were the team's. Every change passed normal review before merge.

What changed

Paper forms and manual collation were replaced by a process where patients respond on their own phones in their own language, and the responsible staff member learns about a problem the same day rather than the following month. The hospital gained measurable patient-experience indicators it can compare over time, and a retrievable record behind every one of them.

Common questions