Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Feedback follow-up router series ~6 min read

A feedback follow-up router on AWS for a few dollars a month

Most small businesses that run a satisfaction survey do the hard part — asking — and then do nothing with the answers. The scores go into a spreadsheet, somebody looks at the average once a quarter, and the person who scored two out of ten and wrote a paragraph about a missed delivery hears nothing at all. This post walks through a small system whose only real job is making sure that person hears something within the hour.

brown and gray metal tools
Photo by Nina Mercado on Unsplash

Key takeaways

  • An unhappy score reaches a person within the hour, with the order and history attached.
  • Speed matters more than wording. A fast short reply beats a slow considered one.
  • The rest are grouped into themes on a fixed list, so trends mean something.
  • It never writes the reply. A generated apology is worse than a short human one.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: survey responses routed to a person with context attachedThree boxes across the top sit outside the AWS account. On the left, Survey responses: a score and maybe a comment. In the middle, Order history: what actually happened to that customer. On the right, Whoever can fix it, reached within the hour. Each connects by an arrow to the AWS account container below. Responses flow down into the account. The order history feeds in what happened. A person receives the response with context. Inside the AWS account are three components in a row. On the left, the Receiver, capturing the score, the comment and who. In the middle, the Router, sending unhappy responses now and the rest to themes. On the right, the Context gatherer, pulling the last order and any open ticket. A note at the bottom says it gathers and routes, and every word sent to a customer is written by a person.AWS ACCOUNTSurvey responsesa score and maybe a commentOrder historywhat happened to themWhoever can fix itwithin the hourReceiverscore, comment,and whoRouterunhappy now,the rest to themesContext gathererthe last order,any open ticketresponseswhat happeneda person, withcontextIt gathers and routes. Every word sent to a customer is written by a person.
Fig 1. Three things outside the account, three pieces inside it. The context gatherer is what turns a ninety-second reply into a good one rather than a generic one.
  • Analytics
  • Front-end & mobile
  • People

Speed over wording

The observation this design rests on is that response time dominates almost everything else about a follow-up. Three honest sentences within an hour of a complaint produce a materially different outcome from a carefully composed paragraph four days later, and the difference is not close.

So the design optimises entirely for the hour: the routing is immediate, the context is pre-gathered so nobody has to go looking, and the reply is short because it is written by somebody who has ninety seconds rather than an afternoon.

What runs (the inside)

  • The receiver. Takes responses from wherever the survey runs, matches them to a customer, and records the score and comment. Part 2 covers matching and the responses that arrive anonymously.
  • The router. Decides urgency from the score first and the comment second, and sends the urgent ones immediately. Part 3 is about why the score alone is not enough.
  • The context gatherer. Attaches the last order, the delivery outcome, any open ticket and whether they have complained before. Part 4 is entirely about this, because it is what makes a fast reply a good one.

One response, end to end

One unhappy survey response from submission to reply, in five stagesA horizontal row of five boxes joined by arrows. Submitted: three out of ten with one sentence. Matched: to a customer. Routed: as urgent, within minutes. Context attached: the order, the delivery and the history. Replied: by a person, in ninety seconds. A note says about forty minutes from submission to reply, of which ninety seconds is a person.ONE UNHAPPY RESPONSE, END TO ENDSubmitted3/10, one sentenceMatchedto a customerRoutedurgent, within minutesContext attachedorder, delivery, historyRepliedby a person, in 90 secondsAbout forty minutes from submission to reply, of which ninety seconds is a person.
Fig 2. The same system as one line. Almost all of the elapsed time is somebody getting to their phone; almost none of it is the system.
  • Networking
  • Analytics
  • Front-end & mobile
  • People

In plain words

A customer scores three out of ten and writes “turned up two days late and nobody told me”. The receiver matches it to their order from the survey token. The router sees a low score and routes it immediately. The gatherer attaches the order, the tracking history showing a two-day carrier delay, the fact that no delay notification was sent, and that this is their fourth order and their first complaint.

Somebody gets that on their phone eleven minutes later, and the useful part is that they do not have to look anything up. They can see the delay was real, that the customer is right that nobody told them, and that this is a good customer having a bad experience. The reply takes ninety seconds and says so.

The theme grouping records it as a delivery-communication issue. Eleven of those in a month is a different finding from eleven scattered complaints, and it points at something fixable: the carrier reports delays and nothing forwards them to the customer.

Design rules that shaped every decision

  • Route unhappy responses within the hour. Everything else in the design is subordinate to that.
  • Attach the context. A reply written without looking anything up is what makes ninety seconds enough.
  • Never generate the reply. A generated apology to an annoyed person is transparent and makes it worse.
  • Follow up on low scores with no comment. They are the more valuable ones.
  • Group into themes from a fixed list, so a trend across months means something.
  • Measure whether following up changed anything, not how many follow-ups happened.

Why this shape

Survey tools mostly stop at collection and reporting, which is the easy half. The half that changes anything is the follow-up, and it fails for a mundane reason: the person who should reply does not see the response until somebody exports a spreadsheet, and by then the moment has passed.

So this design does almost nothing clever and spends everything on the two things that actually determine the outcome: getting the response in front of somebody fast, and putting enough context next to it that replying well takes ninety seconds instead of ten minutes of looking things up.

The next four posts walk through each piece: how responses arrive and get matched, how routing decides urgency, what context gets attached, and how themes and outcomes are measured. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts