Turn repeated complaints into verified Trello repair cards.

This walkthrough is for customer-experience teams tracking repairs in Trello.

AI customer service automation that fixes the repeat question

“Where is the size guide?” appears in three places: a survey, a support ticket and a review. A theme chart tells you people are confused. A more useful workflow finds the page they mean, writes a test a person can repeat and prepares a repair proposal.

The customer-experience owner checks the evidence before assigning work. The advanced path uses a browser agent to try the confusing journey and save what it actually saw.

1. Keep comments connected to the thing people used

Start with a Google Sheet fed by an approved survey or ticket export. Use feedback_id, original_record_id, channel, exact_text, page_url, date, theme, source_quote. Keep known reposts tied to the same original record; do not guess that similar wording means the same customer.

F01, ticket T11: “I cannot find the size guide on the blue-shirt page.”
F02, survey S12: “Does medium mean chest size or garment width?”
F03, copied from T11: same text as F01.
Page: the business's blue-shirt product page.

These are two distinct source records, not three customers. They describe findability and measurement meaning, which may need different fixes.

2. No-code path: turn a theme into a repair card

Schedule a weekly Make scenario. Read new rows from Google Sheets, deduplicate by original_record_id and pass the retained rows to your AI assistant step. Use a small agreed theme list plus unclear so the categories remain comparable.

For each feedback record return primary_theme and exact source_quote.
For each theme propose one reproducible check: starting_page,
steps, expected_information and what remains unknown.
Use only supplied URLs. Do not claim you visited a page or found a bug.
Keep mixed feedback and conflicting experiences visible.

Count source records per theme with Sheet formulas or a Make aggregator. Choose a pilot threshold, such as two distinct records, for a repair proposal; the threshold is a workload choice, not statistical proof. Write proposals to a review tab with the record IDs, counts, sample window and proposed check. End before creating work in Trello.

For the sample, propose opening the product page on a phone, locating the guide and checking whether it defines what “medium” measures. The browser check has not happened yet.

3. Approve the problem before adding another task

The customer-experience owner reads F01 and F02, removes the known repost and performs the proposed check. If the guide is obvious but unclear, edit the proposal to address wording rather than navigation.

Only after verification does the owner create a Trello card with the page, reproduction steps, observed result, desired information and owner. Record its ID beside the theme so next week’s comments attach to the same issue instead of spawning another card.

After the fix ships, repeat the check and compare new feedback over a stated period. Fewer complaints in a small sample is an observation, not proof that the change caused an improvement.

4. Advanced path: send a browser agent to reproduce it

A scheduled worker loads approved public URLs from the review queue. Run Browser Use in a fresh browser profile with a fixed viewport. Give it the proposed steps and ask it to locate the information, record the route taken and capture evidence. Restrict it to your own allowed domains; exclude checkout, account changes and form submission.

A developer can use Browser Use lifecycle hooks to capture screenshots and stop the run. Add a ten-step limit and return blocked for login walls, missing pages or uncertain results. Test mobile and desktop separately; one viewport is not evidence about every device.

The worker stages the observed result and evidence in the repair proposal. The owner checks the browser trace before creating or updating a Trello card. After a human ships the change, the same worker reruns the journey and proposes closure. Only the owner closes the issue. Never present a generated illustration as browser evidence.

5. Test what a theme counter would miss

Try sarcasm, a copied ticket, praise mixed with a complaint, a missing URL and a browser timeout. Expect ambiguity, one source count, both observations preserved, a request for context and blocked status. “Could not load” is not “customer problem confirmed.”

Track verified issues, rejected proposals and repeat complaints with the sample size attached. Stop automated browsing when the site layout changes enough to invalidate the checks; keep the human reproduction steps usable.

Scope: An illustrative build recipe with synthetic examples, not a live-tested integration or a claim of savings. Start with test records. Connector access, API usage and approval features may require paid plans.

AI connection: Use your AI assistant of choice (e.g. ChatGPT, Claude, Gemini). For automation, configure its supported provider API or connector; chat access alone does not supply an API connection. Keep approval outside the model.