← All customers

Customer story

Glovo

Partner onboarding sequences orchestrated as one runtime — email for documents, SMS for time-critical confirmations, WhatsApp for the human-language back-and-forth. One flow definition, three channels, observable per-step.

Sector

Delivery

Channels

Email
SMS
WhatsApp

Headline

+300% partner integration efficiency

The challenge

Onboarding a thousand partners a month, in twenty countries, on three channels.

Glovo's growth depends on a steady stream of new restaurant and store partners coming online — signed up, KYC'd, menu uploaded, payout details verified, first order taken. The onboarding sequence is multi-step by nature: a welcome email with documents, an SMS confirming a verification call, a WhatsApp thread with the regional partner-success agent handling the parts that need a conversation.

At one country, on one channel, this is straightforward. At twenty countries on three channels, with regional differences in which channel partners actually answer on, it's the kind of orchestration problem that quietly becomes a fleet of cron jobs and queue workers. Each one is fine; the collection is not. Retries forget to respect quiet hours, opt-outs on one channel don't propagate to the others, the analytics don't reconcile.

Why Bird

Flows is the runtime; Glovo's code is the flow.

Bird Flows is the workflow runtime under the multi-channel sends. The flow definition is code (TypeScript DSL, optionally YAML), the runtime is Bird's infrastructure, the observability is per-step. Email, SMS, and WhatsApp share the same auth model and the same webhook contract underneath; Flows is the layer that orchestrates them as one sequence.

  • One flow definition, three channels. A single TypeScript file describes the partner onboarding sequence. Each step picks a channel; the SDK call for an SMS step looks like the SDK call for a WhatsApp step.
  • Quiet hours and frequency caps in the runtime.Regional quiet hours are configured once on the flow; the runtime applies them automatically across every channel step. The application code doesn't know what time it is in Madrid versus Lima.
  • Opt-out propagation across channels. If a partner opts out of SMS, the runtime suppresses subsequent SMS steps for that recipient in any flow — without affecting their email or WhatsApp deliverability.
  • Per-step observability. Every step is a span. The dashboard shows where any given flow run is, which step failed, what the retry schedule did. The same data is available on the API for the analytics pipeline.

The integration

A flow definition, in code, deployed via CLI.

The integration surface is small. A flow definition lives in Glovo's repo, deployed via the Bird CLI on every merge to main. The application calls bird.flows.run()when a new partner signs up; everything after that — the email send, the SMS confirmation, the WhatsApp handoff, the wait windows in between — is the runtime's problem.

partner-onboarding.ts
import { BirdClient } from "@messagebird/sdk";

const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });

// Partner onboarding flow: email + SMS + WhatsApp on one runtime.
// Steps run in parallel; each respects per-channel opt-out automatically.

const { data, error } = await bird.flows.run({
  flow: "partner-onboarding-7d",
  to:   { email: "delivered@bird.dev", phone: "+15005550006" },
  variables: {
    partner_name: "Acme Couriers",
    region:       "ES-MAD",
    onboarding_step: "kyc_pending",
  },
});

if (error) throw error;
console.log(data.id);
// → "flow_run_2nB91x..."

The signal back is on the same webhook contract every other Bird channel uses. flow.completed tells the partner-success system the sequence finished; flow.failedescalates to a human; per-step events feed the analytics pipeline. One auth model, one set of webhook handlers, one place to look when something doesn't deliver.

Bird's platform lets us integrate new partners 300% more efficiently. The orchestration that used to live across our codebase now lives in a single flow definition we can read top to bottom.

Luis Grau Granada · Global Operations Director, Glovo

The numbers

+300% partner integration efficiency.

The efficiency number is reported by Glovo and attributed to Luis Grau Granada in the public reference on bird.com. It compares the post-Flows onboarding sequence to the pre-existing patchwork of channel-specific code paths.

+300%

Partner integration efficiency on the onboarding sequence, after migrating the orchestration to Bird Flows.

3

Channels orchestrated on one runtime — email, SMS, WhatsApp — with quiet hours and opt-out handled centrally.

1

Flow definition per onboarding sequence, deployed via CLI, observable per-step in the dashboard.

What's next

From partner onboarding to courier and customer flows.

With the partner onboarding flow as the reference pattern, the same runtime extends naturally to the other two audiences Glovo communicates with: couriers and end customers. Courier onboarding has the same shape — KYC documents, verification, first- order checklist — on the same three channels. End-customer flows are simpler but higher-volume: order confirmations, delivery updates, retention nudges.

The same flow runtime, the same observability surface, the same opt-out model. Adding a channel (voice for high-urgency confirmations, RCS where it's reaching critical mass) is a one-line addition to the flow definition, not a new integration.

Quote attributed to Luis Grau Granada, Global Operations Director at Glovo, carry-forward from bird.com. Efficiency metric reported by Glovo.

Build on the same network.

Flows orchestrates email, SMS, voice, and WhatsApp as one runtime. A test API key is yours immediately.

Start with one channel.
Add the others when you're ready.

A test API key is yours immediately. Production unlocks when you add a payment method and verify a sender.

Get startedRead docsor

Using Claude Code, Cursor, or Codex? Point it at our hosted MCP server: curated Bird tools, a browser sign-in, and no API key. Or install the bird-ai plugin.

Cursor