One application, two boards

Command and Control is ROIkeep's work management application. The same product renders as an engineering board or a marketing and sales board, decided per user, and both boards share one database, so nothing is duplicated.

[ 01 ]

Two boards, one product

The same work management app renders as an engineering board or a marketing and sales board, decided per user.

Engineering and marketing plan in their own vocabulary without running two tools.

  • The engineering board works in Initiatives, Teams, Projects, and Tickets.
  • The marketing and sales board works in Sagas, Chapters, and Tickets.
  • Board access is set per user: the engineering board only, the marketing and sales board only, or both, and both-access users switch boards from the top bar.
  • Both boards share one database, so nothing is duplicated, and data does not cross between boards.
  • Each board has its own URLs and its own theme.

The engineering board

Initiatives grouping projects, tickets underneath, and the top bar switch to the other board.

[ 02 ]

Projects and initiatives

Initiatives and projects are the engineering board's two grouping layers above tickets.

Who leads each project and how far along it is stays visible above the tickets.

  • Initiatives group projects, and one project can be shared across several teams.
  • A project carries a lead, members, a status, milestones, and the date the work is due to finish.
  • Projects move through Backlog, Planned, In Progress, Completed, and Canceled.
  • Milestones attach to a project, and tickets are assigned to them.
  • Links and files attach to a project or an initiative as its resources.
  • Moving a project to backlog requires a written reason.

A project and its milestones

A project's lead, status, milestones, and resources on one page.

[ 03 ]

Sagas and chapters

On the marketing and sales board, a Saga holds Chapters and a Chapter holds Tickets.

Marketing and sales work gets its own structure, scoped to the people inside it.

  • There are no Projects on this board. A Chapter plays that role.
  • A chapter opens straight onto its ticket board, with Overview and Activity as sibling tabs.
  • A chapter carries a lead, members, a status, milestones, and an icon.
  • A saga's chapters read as one grouped list, each with its lead and status.
  • Chapter visibility is membership scoped: a member only sees the chapters they belong to.

A chapter is a working board

A chapter opened straight onto its ticket board.

[ 04 ]

Tickets

The unit of work in both boards, moved through seven statuses on a kanban board or a grouped list.

Work cannot stall silently. Blockers lock status, reopens need a written reason, and every change lands on the timeline.

  • A ticket carries a title, a rich description, an assignee, a due date with time, and a parent project or chapter.
  • A ticket moves through Backlog, Todo, In Progress, In Review, Done, Canceled, and Duplicate.
  • Tickets link as blocked by or blocking, and an open blocker locks the status.
  • Sending a ticket to Backlog or reopening a finished one requires a written reason, stored as a comment.
  • Every ticket gets an identifier from its team, ENG-31 for example, and it is reissued when the ticket moves to another team.
  • An automatic timeline records every change on the ticket, with consecutive changes of the same type collapsed into one entry.
  • Projects and tickets bulk-import from a JSON file, with assignee names matched to real members.

A blocked ticket

The blocking badge and the status lock it enforces.

Who can change what

Workspace roles are Owner, Admin, and Member. Ticket editing is gated to the creator plus elevated roles, and closing a ticket is elevated only. Every check runs on the server, and the interface hides blocked actions rather than failing them.

[ 05 ]

Board and list views

Every ticket and project surface has two views, a kanban board and a grouped list, sharing the same filters.

Day-to-day board work is quick to change and safe to undo, and each person's view stays their own.

  • The kanban board runs one column per status, with drag and drop, a live cross-column preview, and undo with Ctrl+Z.
  • Dragging a card reorders it, and the most pressing work sits at the top of each column.
  • Empty columns collapse into a strip, and any column collapses by hand.
  • The grouped list view shares the same filters as the board, each of its sections paginated on its own.
  • Filters cover status, assignee, creator, project, initiative, dates, and, on the marketing board, saga and chapter.
  • Per-user display options decide which properties show on cards and rows, and they persist across devices.

The kanban board

One column per status, a card mid-drag.

[ 06 ]

Inbox and reminders

One inbox, read as a pinned side panel or a full page, fed by actions and by scheduled reminders.

The system chases stalled work itself, and escalation happens without anyone asking.

  • Notifications fire on mentions, comments, assignments, and status changes.
  • Automatic reminders cover a ticket due soon, a ticket overdue, a ticket sitting in review, and an initiative update overdue.
  • Reminders run on a five minute schedule.
  • In-review reminders go to the lead first, then loop in the team owner after 48 hours.
  • Web push is on once the browser permission is granted, and turns off per user.

The inbox beside the work

The pinned side panel, reminders and mentions in one feed.

Members, sign-on, and board access come from the hub: a person removed there loses access to every board here.

Command and Control is not a separately sold module: every plan ships all four applications.

See both boards running

Book a call and we walk through the engineering board and the marketing and sales board, and you check whatever you need to check.