Skip to content

Automation · Customer service and scheduling

Tell a customer on WhatsApp whether their change is live, by checking GitLab

An AI agent finds the customer's request in GitLab, checks the merge request, its pipeline and the published release, and answers on WhatsApp.

How do I tell a customer on WhatsApp whether their change is published, by checking GitLab?

When a client of your agency asks on WhatsApp whether the change they requested is done, the Met finds the work item for that request in GitLab and checks its related merge requests. It opens the merge request to see whether it was merged and how its pipeline ended, and checks whether a published release came out afterwards. With that it answers in plain words whether the change is published, in review, or whether the deployment failed and the team is looking at it. At the end it leaves an internal comment on the work item so the team knows the client asked.

What starts it

When the customer writes

It starts when a client writes on WhatsApp to ask whether a change they requested is already on their site or app. 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 for an agency that works in GitLab

Customer service team

This is not a named, seeded Met. It is the Met that answers the agency's or business's WhatsApp, with GitLab connected: its work ends when the client knows where their change stands and the team has the question noted.

Run by the customer support Met

Channels: WhatsApp

What you need connected

5 steps · 6 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

    Find the client's request

    The Met lists the work items in the client's project and searches by text for the request they mention, for example the contact form change. If there are several similar ones, it confirms with the client which one it is.

  2. 2

    See which merge request solves it

    The Met opens the work item and asks for its related merge requests. If there is none, it tells the client the request is logged and has no change in progress yet.

  3. 3

    Check the merge request and its pipeline

    The Met opens the merge request with its pipelines to learn whether it was merged, and opens the latest pipeline with its jobs to see whether it ended well or which job failed.

  4. 4

    Confirm whether there is a published release

    If the team publishes releases, the Met lists the project's releases and compares the date of the most recent one with the date the merge request was merged.

  5. 5

    Answer and leave a record

    The Met tells the client whether the change is published, in review or stopped by a failure, and leaves an internal comment on the work item so the team sees the client asked.

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

No. The client only talks to the Met on WhatsApp; everything read and commented in GitLab is done by the account the admin connected.

The Met tells the client the change is on hold and the team is reviewing it. If the owner asks, the Met can also read the log of the job that failed to explain what happened.

Yes. In that case the Met answers with what the merge request and the pipeline say: whether it was merged and whether the pipeline ended well, without naming a release.

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.