Skip to content

Automation · Customer service and scheduling

Log in GitHub the bug a customer reports on WhatsApp and tell them which release shipped the fix

An AI agent logs in GitHub the bug a customer reports, avoids duplicates and tells them which published release shipped the fix.

How do I tell a customer on WhatsApp which version of my app fixed their bug?

When a customer reports a bug in your app or site on WhatsApp, the Met searches the repository for an issue with that problem. If one exists, it adds a comment with the new report; if not, it creates the issue with what the customer said and gives them the number. When the customer asks again, the Met reads the issue: if it is still open, it says so; if it was closed, it reviews the pull request that closed it, searches the published release notes for the one that includes that change and answers which release shipped it, or that the fix is not published yet.

What starts it

When the customer writes

It starts when a customer writes on WhatsApp to report a bug or ask whether it was fixed. There is no trigger to configure: the Met assigned to the line handles it in that conversation.

Nothing to set up. The Met assigned to that channel picks up the conversation and runs the procedure inside it.

Who runs it

Support Met that follows bugs in GitHub

Customer service team

This is not a named, seeded Met. It is the Met that already answers the business's WhatsApp, with GitHub connected: its work ends when the customer has their report number or knows which release shipped the fix.

Run by the customer support Met

Channels: WhatsApp

What you need connected

5 steps · 7 tools

The procedure, step by step

Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.

  1. 1

    Check whether the bug is already reported

    The Met searches the app's repository, with a natural language query, for issues that describe the same bug. If it finds one, it adds a comment with the new report.

  2. 2

    Create the issue

    If there is no similar one, the Met creates the issue with a clear title, the customer's description and the steps they described, and sends the customer the issue number on WhatsApp.

  3. 3

    Check the issue status

    When the customer asks whether it is fixed, the Met reads the issue. If it is still open, it says the team is still working on it; if it is closed, it looks at which pull request closed it.

  4. 4

    See when the fix went in

    The Met opens that pull request and reviews its details to learn whether it was merged and on what date, before looking for the release that includes it.

  5. 5

    Find the published release

    The Met gets the latest published release and lists the earlier ones, and searches their notes for the issue or pull request number. It tells the customer which release shipped the fix, or that it is not in any published release yet.

Before you start

What you need ready

The Met solves none of these for you. If one is missing, the automation stops there.

The limits

What this automation does NOT solve

Better said here than discovered halfway through the rollout.

FAQ

Questions about this automation

The Met can still say whether the issue is open or closed and whether the pull request was merged. What it cannot do is name the release, because it does not exist in GitHub.

Only if the repository is public. In a private repository, the customer learns everything on WhatsApp and never needs a GitHub account.

The Met finds the existing issue and adds a comment for each new report, so your team sees how many people have the problem without duplicate issues.

Keep going

Other automations built on the same tools

Want this automation running on your own data?

We will show it to you with your accounts connected, not with a canned demo.