Kanban for marketing teams: from request to shipped

The problem is not the work, it is the handoffs

Most marketing teams track campaigns in a spreadsheet, a chat thread, and a weekly meeting where everybody says "almost done". None of those three reliably records when a draft went to review, who it went to, or how long it has been sitting there — so the first hard signal that a launch date is in trouble is the launch date.

Kanban for marketing teams fixes that by making the handoff the thing you can see. A card is an asset — a landing page, an email sequence, a case study — and its position on the board is its status. When somebody asks where the Q3 campaign is, the answer is a glance rather than an archaeology dig through Slack.

Set up your marketing board — free for up to 3 users

A board shaped like your campaign pipeline

Lists are yours to name, reorder and colour, so the board models your real process instead of a generic template. A marketing team usually lands somewhere close to:

Requests → Brief → In Production → Review → Scheduled → Shipped

Each card carries the whole asset: owners, start and due dates, labels for channel or campaign, checklists for the production steps, attachments for the working files, comments for the feedback, and a full activity history of who moved it where. Ownership lives on the card, so "who has this?" stops being a question anyone has to ask out loud.

Intake that ends "who owns this?"

Requests reach marketing however they like — a Slack message, a corridor conversation, a forwarded email. The failure is not where they arrive, it is that they arrive without an owner. In Otper, new requests become cards in the board's first list, and you triage from there:

• From Slack — /otper create-card <title> | <description> in a linked channel, or the Otper Actions shortcut on any message, where the first line becomes the title, the rest the description, and files attached to the message become card attachments. Because Slack identities are linked to real accounts, the card has an author rather than a bot.
• From your own systems — a request form, a CRM, or an internal tool can create cards through the GraphQL API, so intake is automated instead of retyped.
• In Tickets view — an inbox-style view of the board for triage: work down the queue, give each card an owner and a due date, and it joins the flow.

Name the bottleneck instead of guessing at it

Most teams have a sense of which stage holds work up — review, usually — and no number to put behind it. Otper measures it: bottleneck reporting gives the average days cards spend in each list, ranked and scored, so the slowest stage is named rather than argued about. Alongside it, stuck work lists cards with no activity for seven days or more, and a per-member breakdown shows how many cards each person is holding in each list — which turns "review is slow" into "these four assets are waiting on one reviewer". See what delivery reporting covers.

WIP limits, so production cannot outrun review

Every list takes two work-in-progress limits. A soft limit warns when the stage is at capacity; a hard limit blocks the move outright. The hard limit is enforced on the server rather than in the interface, so it also holds for bulk moves, newly created cards, reopened cards and automations — the routes that would otherwise slip past it.

Limits sit on stages rather than on people, which is the right place for them: capping Review at six cards protects the reviewer regardless of who wrote the six. For load per person, the workload report shows each person's share of active work against the team average and flags anyone carrying too much — so "we're at capacity" becomes a number instead of a feeling.

Launch dates drawn from the same cards

Kanban shows flow; a timeline shows dates. You need both to answer "can we actually hit the launch?" Board, List, Gantt and Tickets are four views of one dataset — give a card a start date and a due date and it appears as a bar in Gantt view, with no second plan to keep in sync. The due-date spread report groups cards by when they fall due, so next month's crunch is visible this month. See how the timeline view works.

Status reports assembled, not written

The weekly update is mostly data collection: what shipped, what is in flight, what slipped. Each of those is already a number the board produces — completed cards and throughput for what shipped, work in progress for what is live, overdue and delay-risk cards for what slipped. Pick a date range and the boards you care about, and export the result as CSV or PDF. Nobody assembles a slide the night before, and the meeting shrinks to the decisions only people can make.

Automations keep the board honest without anyone tidying it: when a card lands in a list, a label goes on, every checkpoint is ticked, or a due date arrives, rules can move, label, assign, comment on, or close the card.

What it replaces

How to set it up this week

1. Create one board per team, and name the lists after your real stages — including the waiting ones, like Waiting on legal or Waiting on client. A stage you hide is a stage you cannot measure.
2. Link your marketing Slack channel to the board, so requests become cards where they are already being made.
3. Put a hard WIP limit on Review before anyone argues about it. Six is a reasonable place to start; adjust once you have a week of data.
4. Add start and due dates to anything with a launch date, so it draws itself in Gantt view.
5. Read the bottleneck and stuck-work reports every Monday, and take the status meeting down to exceptions.

Related reading: how to set up a board, connecting Slack, and why kanban scales marketing work.

Common questions