We’ve built an automated workflow that pulls every Feefo review straight into the support ticket it relates to and uses Claude to help our team understand what’s really behind a difficult review, all within minutes of a customer submitting their feedback. Here’s how it works, and what we learned building it.
Setting the scene
We collect customer reviews through Feefo, the review platform behind the Platinum Trusted Service Award badge you’ll see on our site. After a support ticket closes, customers are asked to rate the experience out of five stars, leave a short note, and give a Net Promoter Score. That feedback matters to us both operationally and reputationally, and it directly informs how we run the service desk.
The problem was never collecting the feedback, it was what happened afterwards. We’ve always read every review on Feefo, but reviews landed on Feefo and stayed there. A five-star review with a kind word about an engineer wouldn’t always reach them. Since reviews are anonymous and carry no ticket reference, as much as we’d try to inform the engineer, unless a manager connected a review to a ticket and passed it on, they would never find out. If a review flagged a problem, we always looked into it to work out what went wrong, fix it, and make sure it didn’t happen again, but doing that well took real, manual effort, which is where the pain came in.
The pain this was causing
Before this workflow existed, four things consistently slowed us down:
- Feedback sat unseen for hours. Previously we were manually checking for new reviews, so a negative review submitted at midday might not reach the service desk until the evening sync ran, leaving a genuinely unhappy client’s feedback unnoticed for several hours.
- Analysis was manual and time-consuming. Working out what had gone wrong meant moving between the Feefo review platform and our helpdesk platform manually, and for longer tickets, reading through a lot of messages and history just to piece together what had happened.
- Judgement wasn’t consistent. Different managers naturally reached different conclusions from the same review, so the same kind of review could be treated quite differently depending on who picked it up.
- Reporting was manual too. Working out how many high-scoring reviews an engineer had received meant manually counting entries on the Feefo dashboard, ticket by ticket, with none of it feeding into our reporting platform.
Under the bonnet: how the workflow actually runs
The live workflow in n8n runs like this:
- Two triggers. A webhook fires the moment new feedback is posted to Feefo, backed by a scheduled catch-all run each morning in case anything slips through.
- Authentication and fetch. The workflow fetches a fresh access token from Feefo (rather than storing one long-term), then requests only the reviews submitted since it last ran, splitting the bulk API response into individual records mapped to fields we can use: customer name, star rating, written feedback, and NPS score.
- Matching to a ticket. The workflow authenticates separately against our ticketing platform and loops through each unmatched review to find its corresponding ticket.
- The branch point. Higher-scoring reviews are posted straight to the ticket along with the NPS score, and that review is then marked as processed so it will not trigger the workflow again. Lower-scoring reviews go into an extended loop for closer analysis.
- The AI step. For lower-scoring reviews, the relevant ticket, including its message history, timestamps and status changes, is pulled temporarily into an internal database and passed to our LLM (our current LLM of choice for this workflow is Anthropic’s Claude model) and analysed. The model assesses whether the feedback was fair given the evidence, and summarises the likely causes: for example, it might suggest that the engineer took too long to response or misunderstood the original request.
- Writing it back. The summary is posted into a separate, access-controlled tab on the ticket, which triggers our internal review process. The temporary database holding the ticket data is then wiped, every single time.
How we use AI in the workflow
For the daily back-up check workflow we built, we only used AI as a research assistant (to work out what the platforms exposed and how to pull the data we needed), as the workflow dealt purely in verifiable fact, a back-up either ran successfully or it didn’t.
In this workflow we used AI in that same research capacity during development, but also operationally, because the underlying problem is different in kind. A review isn’t a fact to be checked, it’s an opinion to be understood. A ticket can breach its service level and still have been a good experience, and one that finished on time can still have left a client frustrated. That’s a judgement call, and exactly the kind of task where a language model, given the right evidence, can produce a useful first-pass answer for a human to verify, rather than a definitive one to accept blindly.
Notable challenges
Defining “wrong” was harder than the plumbing. There’s no fixed rule for what makes an experience bad, so we had to think in terms of underlying signals instead: was the language in a client’s messages urgent, and did our response time match that? Were questions actually answered, or was the client asked to repeat themselves? That meant giving the model the full ticket context, not just the review text, and being deliberately conservative about model choice and output length so results stayed useful rather than open-ended.
The API itself added friction. The Feefo API returns a day’s reviews as one bulk response that has to be split and mapped before anything downstream can use it, and every ticket then has to be matched individually through a loop.
Access, tools and governance
Building this required API access to Feefo, API access to our ticketing platform, and an Anthropic API integration inside n8n. A few deliberate safeguards keep it safe:
- Fresh tokens, never stored. Access tokens for both external platforms are fetched fresh at the start of each run rather than kept long-term.
- Nothing retained. The AI model only ever sees a temporary copy of the relevant ticket, pulled in for that single run and wiped from the internal database immediately afterwards, so no client or ticket data is retained beyond the run itself.
- Capped output. Response length from the model is capped, partly for cost control and partly to keep output focused.
- Controlled visibility. The AI-generated summary sits in a separate, permissioned tab on the ticket rather than being automatically visible to the client, so who sees it remains a deliberate choice.
Results and impact
| Before | After |
| Reviews sat on Feefo, invisible to the engineer they were about | Feedback lands on the correct ticket within five to ten minutes of being submitted |
| Negative feedback could sit unseen for hours after the scheduled sync ran | Every review triggers the workflow in real time via webhook |
| Analysing a low-scoring review meant manually reading through ticket history | The AI provides a first-pass summary as a consistent starting point |
| Judgement varied depending on who reviewed the ticket | Every reviewer works from the same AI-generated summary |
| Engineer-level reporting meant manually counting reviews on the Feefo dashboard | Reporting is pulled directly from our ticketing platform on demand |
The knock-on effect has been just as valuable as the time saved: positive feedback is now visible to the engineer it’s about, which has already surfaced genuine praise for individuals that would previously have gone unrecognised.
Lessons we’re taking forward
Ship small and let it evolve. The first version of this workflow took a few hours to build and did nothing more than post a star rating and a note onto a ticket on a schedule. Real-time triggering and the AI analysis both came later, once it was clear there was more value to extract from the same data, and we expect it to keep changing as we find new uses for it.
Know where automation should stop. Every stage of this workflow has a manual fallback: if n8n or the AI step doesn’t run, the raw feedback still lands on the ticket and still gets checked by a person. Automation here speeds up and standardises a process that already existed; it was never allowed to become the only version of that process.