Use case: agencies
Client projects in order. Clients in the loop.
One board per client project, one wiki space per client, and read-only links for the people you work for. Your team sees everything. Each client sees only what you share.
- Design and web agencies
- Marketing agencies
- Freelancers and studios
The problemEvery client project lives in a different tool, folder and chat.
One board per project, the same setup every time.
Save the lists and labels of a good board as a template, and start the next project from it.
- Board, swimlane, calendar and table views of the same tasks.
- Access per team or person: viewer, editor or manager.
- Recurring tasks for monthly reports and check-ins.
- Task keys such as WR-7 make work easy to name in calls and emails.
The problemClients ask for updates, and you write status reports by hand.
Give each client a public board.
Publish a project board as a read-only page and send the link. The client follows progress, and you stop writing the same update twice.
- Any number of public boards on every plan.
- Read-only: clients cannot change anything.
- Display names are shown. Email addresses never are.
- Search engines are told not to index it.
A public board shows every published task on it. Keep internal work on a separate board.
The problemBriefs and handover documents are buried in email attachments.
Briefs and handovers in the wiki, shared per client.
Give every client a wiki space. Share the pages they need through read-only links.
- As many share links per page as you need, for example one per client contact.
- Add a password and an end date. Revoke a link at any time.
- Share one page, or a page with its subpages.
- Export pages as Markdown when the project ends.
The problemChange requests come in by phone, chat and email, and nobody has the full list.
One request form per client.
Give each client board its own public form. Requests land in the list you choose, with the labels you allow.
- The sender confirms with a code sent by email.
- Files are supported.
- New requests stay unpublished until you publish them, so they never show up on a public board by accident.
Features you will use
Every one of them is on every Kanroo Cloud plan.
Questions and answers
Do clients need to be members?
Not to follow along. Public boards, wiki shares and public forms are made for people outside your organization. If a client should edit tasks, invite them as a member with access to their own board only.
Can one client see the work of another client?
Not if you keep them apart. Board and space roles decide who sees what, and every public board and every share has its own link.
Can public pages use our own domain?
Not yet. Custom domains are not built. They may come with community interest, so request it through the feedback form.
Request a featureHow is Kanroo Cloud priced for an agency?
Per member of your organization. People who only view a public board or a shared page, or send a form, are not members.
Other use cases
- Service deskPublic forms and email create tasks. Labels sort them, a public board shows the status, and the wiki answers common questions.
- Software teamsReleases and bugs on boards, specs in the wiki, and your coding agent connected through MCP. REST API and webhooks for the rest.
- Public sectorWorkspace data in the EU, an open-source core you can self-host, keyboard and screen-reader design, and no built-in AI.
Set it up on your own board.
Every feature is on every Kanroo Cloud plan. Try it alone for free, then invite your team.