Detect friction in your product in real-time — and route it to the right people before users churn.


Most product managers find out about broken experiences too late. A signup flow fails silently for three days. A payment error spikes over a weekend. A new feature gets abandoned by 80% of users within the first session — and nobody notices until the Monday standup.

This tutorial walks you through building a system in Make.com that watches for critical customer journey events, evaluates whether they signal a real problem, and automatically alerts your team, creates tasks, and logs everything for analysis. No code. No data engineering team. Just a PM who refuses to fly blind.

By the end, you'll have a working real-time product health monitoring system that runs itself.


What You're Building

The system has three layers:

Layer 1 — Event Ingestion. Customer journey events flow into Make.com from your analytics, backend, or tracking tools. These are things like signup completions, payment failures, feature usage milestones, and onboarding drop-offs.

Layer 2 — Evaluation & Threshold Logic. Make.com evaluates each event (or batch of events) against rules you define. Is the signup failure rate above 5%? Have more than 10 users abandoned checkout in the last hour? Is feature adoption below the target you set? This is where raw data becomes signal.

Layer 3 — Response & Routing. When a threshold is breached, the system fires. It sends Slack alerts to the right channel, creates Jira or Linear tickets, logs the incident to a Google Sheet or Notion database, and — optionally — triggers an AI summary explaining what happened and what to investigate first.

The result is a system that turns your product's event stream into an operational nerve center.


Prerequisites

Before you start, make sure you have the following:

A Make.com account. The free tier works for testing, but you'll want a paid plan for production use since this system runs on scheduled intervals.

A data source for customer events. This is the most important prerequisite. You need some way of getting event data into Make.com. The most common options are a webhook from your backend (your engineering team sends an HTTP POST to a Make.com webhook URL whenever key events fire), a database or data warehouse you can query via API (PostgreSQL, BigQuery, Supabase), an analytics tool with an API (Mixpanel, Amplitude, Segment), or Google Analytics 4 via the GA4 Data API. This tutorial will show the webhook approach as the primary method and the API-polling approach as an alternative, since those cover the widest range of setups.

Slack (for alerts). You can substitute email, Microsoft Teams, or Discord — the principle is the same.

Google Sheets or Notion (for logging). Used as a lightweight incident log.

Jira, Linear, Asana, or your task tool of choice (for creating action items). Optional but recommended.