How to set up a Kanban board in Otper

A well-designed board gives your team one place to see what is new, what is active, who owns it, and what is blocked. Use this guide to build a board that stays useful after the first week.

An Otper Kanban board with Inbox, TODO, In Progress, and Done lists
An Otper board uses lists as workflow stages and cards as units of work.

Step-by-step setup

  1. 1. Create one board per stream of work

    From the dashboard, create a board and name it after a specific stream, project, or queue. Examples include Website Launch, Support Escalations, Hiring Pipeline, or Sprint 14. Keeping each board focused makes ownership and reporting easier to understand.

    When you create a board you can also customize its key and slug to short, unique values. The key prefixes every card ID on the board (for example, WEB-12), and the slug forms the board’s URL, so clear values here keep cards and links easy to recognize later.

  2. 2. Shape lists into your workflow stages

    New boards start with Inbox, TODO, In Progress, and Done. Treat each list as a stage of work. Add stages such as In Review, QA, Waiting, or Blocked only when they represent real handoffs. When cards collect in one list, the bottleneck is visible immediately.

    Once the stages are right, reporting status stops being a separate chore: dragging a card to the next list is the status update. There is no standup spreadsheet to reconcile afterwards, and because the move is recorded on the card, you keep a trail of when work entered and left each stage — which is what makes a queue that is quietly backing up visible on the board rather than in a retro six weeks later.

  3. 3. Add work as cards

    Add one card per task, request, bug, or deliverable. Open the card to assign members, set start and due dates, apply labels, add checklists, attach files, create polls, and keep comments in context. Read the card guide.

  4. 4. Invite members and set board access

    Invite teammates from board settings or with a board invite link. Assign a role that matches the work they need to do, then use board settings to manage members, labels, limits, closed cards, custom fields, webhooks, and other board-level controls.

Board views: Board, List, Gantt, and Tickets

A standup, a schedule review, and a support queue all need the same board read a different way. Rather than maintaining a separate tracker for each, switch views over the same cards:

  • Board - Kanban columns for daily execution and bottleneck detection.
  • List - a compact card list for scanning, sorting, and triage.
  • Gantt - a timeline for scheduled work, due dates, and cross-list planning.
  • Tickets - an inbox-style split view for request-driven work, with unread markers on cards you own or watch.
One board, four ways to read it. Switching views changes only your own display — the cards, owners, and history stay the same.

Switching is a display change for you alone: it moves no cards, changes no data, and does not affect what teammates see. That makes it safe to change view mid-conversation — open List to triage a backlog, jump to Gantt when someone asks whether a date is at risk, and go back to Board to run the standup, all against one set of records. Each board remembers the view you last used, and the view is carried in the URL, so a link you paste into a channel opens on the view you meant the reader to see.

Otper Gantt view showing cards on a weekly timeline grouped by list
Gantt view places the same cards on a timeline so schedule risk is easier to spot.

For queues where work arrives one item at a time — support escalations, bug intake, or incoming requests — switch to the Tickets view. It lays the board out like an inbox: a scannable list of cards on the left and the selected card open beside it on the right, so an owner can work straight down the queue without losing their place. Cards you own or watch show an unread marker the moment there is new activity you have not opened yet, so nothing waiting on you slips past. It is the same board and the same cards, read the way a support or intake team works.

Example workflow

For a delivery project, start with Inbox, TODO, In Progress, In Review, and Done. Require an owner before a card leaves TODO, use labels for workstream or priority, and review the Gantt view weekly to catch late or overloaded work. See the project management guide.

Setup checklist

  • One board per project, queue, or operational stream
  • Lists named after real workflow stages
  • Labels agreed before the board fills up
  • Members invited with appropriate board roles
  • Every committed card has an owner and due date
  • Board, List, Gantt, and Tickets views reviewed by the team

FAQ

How many boards should a team have?

Use one board per active stream of work. If two boards need the same cards or the same daily discussion, they are probably one board.

Can I change lists after work has started?

Yes. Rename or reorder lists as the workflow matures. Existing cards keep their activity history.

Does changing the board view affect my teammates?

No. The view is yours: it changes only how you are reading the board, not the cards or anyone else's screen. Each board remembers the view you last used, and the view is included in the board URL so you can share a link that opens on a specific view.

Can I run a support or request queue on a board?

Yes. Switch to the Tickets view for an inbox-style layout that shows open cards in a scannable list with the selected card open beside it. Cards you own or watch show unread markers when there is new activity you have not opened yet, so incoming requests are easy to work through one at a time.

Troubleshooting

ProblemFix
Cards pile up in one listTreat that list as the bottleneck. Add capacity, split the stage, or limit new work entering it.
A member cannot move cardsCheck their board role and confirm the board or card is not closed.
A teammate cannot see the boardInvite them to the board or send a valid board invite link, then confirm their role.

Related guides

Ready to build your first board?