Automating UAT Feedback with Make.com, AI and Trello

Since March I've been working with the Creative Diversity Network to launch Diamond 2, a product which collects diversity data from the UK broadcasting industry so that broadcasters and production companies can assess how diverse their programmes are. My contribution to the project is to manage the UAT process for CDN and to support the broadcasters with their individual testing needs.

As part of that work I wanted to create an automated pipeline for broadcaster users to supply their feedback, so that the CDN team weren't overwhelmed with emails. Through my experience of running projects with multiple stakeholders I've found email to be a poor format. Too many people end up copied into the chain, most of them unnecessarily. Users reply-all, and not always to the latest message. It's a difficult source to keep track of and details are easy to miss. To sum it up, discussion and reporting via email is a mess, and decisions should never be made that way.

For support and feedback processes I prefer dedicated tools. JSM is one, but it's designed for much higher-volume support operations. What this project needed was different: a short window in which broadcaster users tested the product before it went live and fed back any bugs they spotted. That doesn't justify a full off-the-shelf product with a large setup investment and training overhead. I needed something lightweight that could be implemented quickly and effectively, with an eye on both efficiency and cost.

My first step was to plan what the process actually needed, focusing on the workflows, deciding which ones were required, and equally deciding not to over-engineer the solution. That second decision mattered just as much as the first: a complex multi-step build would have added setup and maintenance costs for no real gain.

Starting with the form

I decided to start with a submission form as the trigger point. All good feedback starts with a well-designed form. I have a lot of experience here, designing forms for multiple clients and for the BAFTA Awards through their awards entry management product, Nucleus. Users will often fire off an email without thinking, but completing a form requires a commitment. They have to think before they submit, and the act of pressing a submit button makes people pause. That in itself reduces the volume of correspondence and improves the quality of what comes in.

I landed on Tally as the solution. It has a generous free tier, it's clean and sophisticated, and it offers a decent amount of functionality.

Choosing the operations centre

I knew I wanted AI involved in the process, summarising submissions, flagging duplicates and so on. After reading about Make Agents while completing their courses in March 2026, they looked like a good fit for this workflow.

The harder decision was what to use as the operations centre. I wanted something that required little training, was easy to set up and could be maintained without specialist knowledge. Researching with AI, I reviewed and discarded a number of support products and project management tools. I pared the requirement back to the simplest feature that would do the job: a Kanban board that could be customised.

I settled on Trello. It has a good range of Make modules, it's cheap and lightweight, and it does Kanban properly.

For this process a Kanban board has clear advantages over email. Each submission creates its own card that can be managed independently. Comments build a visible history against that card. The board itself shows, at a glance, where every piece of feedback sits. Each card also carries Trello's own sequential number, surfaced on the front of the card by the Card Numbers Power-Up from Reenhanced and presented to testers as D2UAT-XXXX. Every submission therefore has a reference that both sides can quote.

Once the operations centre was settled, the rest of the flows worked themselves out.

Following the feedback through

A tester submits through the Tally form. If they are simply confirming that a test passed, the process ends there with a confirmation email. Tally is the system of record for sign-offs, so there is nothing to create and nothing to chase. If they are reporting a problem, the automation pulls every open card off the board and hands it to an AI agent along with the submission. The agent decides whether this is something new or a repeat of an issue already logged, then either creates a card with a clean, structured description or appends the report to the existing one. Either way the team is notified in Slack within seconds.

Handing the agent the whole board, rather than letting it run its own searches, was a deliberate choice. At UAT volumes the full card list fits comfortably into a single call, and it removes a class of failure where a badly chosen search term hides an obvious duplicate.

From that point the Trello board is the operational hub. The Product Coordinator never logs into Make. She works the board, and moving a card between lists is what triggers everything else. A move to Needs Info drafts and sends a professionally worded email asking the tester for more detail. She writes plain notes in a comment and the tester receives a proper email. A move to Waiting for Fix raises the corresponding issue with the platform provider in Linear, carrying the description, the priority and the test case reference across, so every bug stays traceable back to the test that found it.

Testers reply by email, because people do. A final automation watches the shared mailbox, discards the auto-replies and out-of-office notices, and attempts to match genuine replies back to the right card. Successful matches become comments, keeping the conversation attached to the issue rather than scattered across inboxes.

That last leg is the one that has proved least reliable. Some replies have not made it onto the board, and the Coordinator still has to keep an eye on the inbox rather than trust the board to be complete. I have deliberately not chased it hard: the failure is intermittent, diagnosing it means unpicking individual messages, and the cost of doing that during a live testing window is higher than the cost of a human occasionally checking a mailbox. A lightweight system earns its keep by not demanding attention at the worst possible moment.

The automation disappears

The part I'm most pleased with is that the person running this every day never sees the automation at all. She sees a Kanban board with cards on it, and she moves them. The list a card sits in is the interface.

That was not an accident of the build; it was the reason for choosing Trello in the first place. Anything requiring the Coordinator to learn a second tool, or to remember which button fires which process, would have added training cost to a short project and created a single point of failure in the one person who understood it. A board is legible to anyone who looks at it, including people who join halfway through.

It also fails gracefully. If every automation stopped tomorrow, the board would still be a working triage system, just a manual one. Nothing about the process depends on the plumbing being up.

The workflow

Tally → Make.com → OpenAI → Trello → Slack / Mailgun / Outlook / Linear

• Tally captured structured feedback.
• Make.com orchestrated the workflow.
• OpenAI, inside Make's AI Agent modules, handled deduplication, classification and email drafting.
• Trello became the operational hub, with card numbers surfaced as D2UAT references by the Card Numbers Power-Up.
• Slack surfaced anything needing attention.
• Mailgun handled outbound communication.
• Outlook monitored replies.
• Linear received confirmed defects.

The polling runs every fifteen minutes during working hours, Monday to Friday; only the initial confirmation is instant. That was a conscious trade-off. It keeps running costs down, and for a testing process a follow-up email arriving within the working day is entirely acceptable.

How it's gone

The full pipeline went live at the end of June, ahead of the wider broadcaster testing window, with a written guide issued to the team and a single instruction: everything goes through the form, internal team included. That last part matters more than the automation. A pipeline only works if there is no easier path around it.

With the first window complete, the workflow has done its job. HTML-styled emails made the communication unambiguous. Triage happened in one place rather than across six inboxes. Confirmed defects reached the product provider in a consistent shape, with the test case reference attached, which is what makes a bug traceable back to the test that found it.