Campaigns

Campaigns let you group meeting requests for attribution and reporting. Each campaign is bound to a team and gets its own scheduling email address. When a meeting request is attached to a campaign, SkipUp tracks it through the funnel and surfaces booking metrics back per campaign.

When to use campaigns

Campaigns solve three common attribution and rollup problems:

• Conference outreach — Cut a campaign for an event (“NAA 2026”) with its own scheduling email. Hand the address out at the booth or in pre-event invites and every meeting that comes in is auto-attributed to the campaign.
• Quarterly rollups — Spin up a per-quarter campaign per team to track win rate over time. The booking-rate metric stays scoped to the campaign even after the quarter ends.
• Multi-channel marketing — Use the campaign description to capture the channel (“LinkedIn ad”, “newsletter”) and route to the same team. The source snapshot survives even if the campaign is renamed later.

How campaigns route meetings

Each campaign has a scheduling email that follows the pattern <campaign-slug>.<workspace>@skipup.co. Mailing the campaign address routes the meeting request through the campaign’s team using whatever assignment mode that team uses (round robin, collective, or manual). The campaign is automatically attached, so reports and webhooks see attribution from the first message.

You can also attach a campaign explicitly when creating a meeting request via the API by passing campaign_id. This is the typical pattern for CRM-triggered Zaps that already know which campaign a deal belongs to.

Booking metrics

Each campaign tracks three numbers in the SkipUp app:

Metric	What it counts
Leads	Meeting requests attributed to the campaign
Bookings	Leads that resulted in a booked calendar event
Booking rate	Bookings ÷ Leads as a percentage

The same numbers surface on the Campaigns API as meeting_request_count, meetings_booked_count, and booking_rate.

Lifecycle

Campaigns have an active state and optional start and end dates:

• Active — Campaigns are active by default. The scheduling email accepts requests and the campaign is attached to any meeting routed through it.
• Date range — Optional starts_at and ends_at are useful for time-bound campaigns (a conference, a launch week). They are advisory: requests outside the window still attribute, but the campaign is flagged as inactive in the UI once ends_at has passed.
• Archived — A workspace admin can archive a campaign. The scheduling email stops routing new requests; existing requests keep their attribution.

Workspace flag

Campaigns are gated on a workspace-level flag. Contact support if you don’t see the Campaigns page in your workspace navigation and we’ll enable it.

See also

• Campaigns API reference — REST endpoints for managing campaigns programmatically
• Attaching campaigns to meeting requests — Pass campaign_id at creation time for CRM-triggered automations
• Webhook event payloads — Every meeting_request.* event carries the campaign attribution block when set
• Teams — Campaigns route through a team; pick the team’s mode based on how you want the campaign distributed