Space Templates: One-Click Workspaces for Every Team
See what each of Openbook's 12 space templates sets up, how to customize the rooms afterward, and when starting from a blank space makes more sense.
The hardest moment in any new workspace tool is the empty screen. You know your team needs a better way to work. You do not necessarily know, on day one, whether that means a kanban board or a table, a wiki or a docs tree, a check-in routine or a status room. Blank tools quietly transfer the product design job to you.
Openbook's answer is space templates: 12 one-click starting points that provision a working set of rooms and seed them with starter content, so the first thing your team sees is a space that already works. Pick the template closest to your team, and you skip straight past the empty screen to the interesting part — adjusting a working space to fit you exactly.
This guide covers all 12 templates, who each is for and what its composition centers on, how to customize a space after the template does its work, and the honest answer to when you should skip templates and start blank.
How templates work
A quick grounding first. Openbook is structured as Organization → Space → Room. A space is a team's workspace, and rooms are its working surfaces — there are 18 room types, from a social Feed to a Kanban Board to Proofing for creative review. Composing a space means choosing its rooms.
A space template makes that composition for you, in one click, in two ways:
- It provisions rooms — a set chosen for a specific kind of team, so a software team gets sprint tooling and an HR team gets culture and time-off tooling, not the other way around.
- It seeds content — starter structure inside those rooms, so boards are not empty grids and the space reads as "in progress" rather than "some assembly required."
Crucially, nothing a template does is locked. Every room it creates can be renamed, reordered in the sidebar, restricted with per-room visibility, or deleted outright. Every room it did not create can be added later in seconds. A template is a head start, not a contract. That is why the practical advice throughout this guide is: pick the closest template, then edit.
All 12 templates are available on every plan, including Free — see pricing for what changes between tiers.
Here is the full lineup at a glance, with the room that anchors each composition and the first ritual worth scheduling in it:
| Template | Best for | Anchor room | First ritual to schedule |
|---|---|---|---|
| Marketing | Campaign and content teams | Table Board (content calendar) | Weekly campaign review on the feed |
| Sales | Pipeline and account teams | Table Board (pipeline) | Monday pipeline pass with bulk updates |
| Design | Design and creative teams | Proofing | Review rounds with per-reviewer decisions |
| HR | People and culture teams | Feed | Monthly pulse survey via Check-in |
| Ops | Operational and process teams | Kanban Board (request queue) | Weekly queue triage |
| Finance | Finance and accounting teams | Dashboard | Close-checklist review |
| Software | Engineering teams | Kanban Board (sprints) | Daily async standup via Check-in |
| Product | Product managers | Project Status | Weekly stakeholder update |
| Startup HQ | Whole small companies | Feed | Friday wins post |
| Single Project | Cross-functional projects | Gantt | Weekly status narrative |
| Agency | Client delivery teams | Proofing | Client-visible weekly update |
| Support | Support teams | Kanban Board (ticket queue) | Shift check-ins |
The sections below take each template in turn, grouped the way teams usually shop for them: by department, by product and engineering, by company level, and by client-facing work.
The department templates
Six templates map to classic departments. If your team has a name that appears on an org chart, one of these probably fits.
Marketing. Built around the rhythm of campaigns: a content calendar you can run on a Table Board (the table template library includes content calendars out of the box), a production pipeline where drafts move through stages, a feed for launches and wins, and space to write briefs in Docs. Marketing teams tend to add a Dashboard early — stat tiles and charts wired to the production board make campaign reporting continuous instead of monthly — and a Whiteboard for campaign brainstorms, where templates like customer journey maps live.
Sales. Centered on the pipeline. A table board is the natural spine here — its ~40 templates include a sales pipeline, and its column types (status, people, number, date, dropdown, progress) map cleanly onto deal stages, owners, values, and close dates, with bulk actions for the end-of-quarter cleanup. Around the pipeline: a feed for wins and kudos (ring the bell publicly), docs for playbooks and call notes, and a dashboard that turns the pipeline into stat tiles a sales leader checks instead of asking.
Design. Composed for making and reviewing visual work. The distinctive room is Proofing — annotations pinned directly on artwork, versioning, and formal approve or changes-required decisions per reviewer — which replaces feedback-by-screenshot forever. Alongside it: a kanban board for the request and production flow, a whiteboard for exploration, and docs for design principles and research notes.
HR. The people-team composition doubles as a mini-intranet: a feed for announcements and culture, Event rooms for company gatherings with RSVPs, Time Off for PTO requests, approvals, the who's-off view and the team capacity chart, and Check-in for pulse surveys with green-yellow-red mood tracking. HR teams often extend it with Group rooms — member-run communities with their own feeds and rosters — as homes for ERGs and clubs.
Ops. Operations work is recurring work: request queues, process checklists, vendor and asset tracking. This template centers on boards for the queues and cadences, docs for the SOPs that make processes survivable, and status reporting for the standing "where are we" questions. Ops teams get outsized value from Q&A too — "how do I request a laptop" belongs in a votable, searchable answer, not in someone's DMs for the ninth time.
Finance. Built for cycles and reporting: boards for close checklists and budget tracking, docs for policies and memos, and a Dashboard where the manual-data widgets earn their keep — numbers that live in your accounting system can still be presented alongside everything else, next to progress bars for the close. Per-room visibility matters most here of all the department templates; finance spaces usually keep some rooms restricted to certain people from day one.
The product and engineering templates
Software. The deepest work-management composition, anchored by the Kanban Board in full agile mode: backlog, sprints, scrum board, sprint insights, story points, checklists, custom fields, and 36 board templates. Around the board: Check-in for async standups (what I did, what's next, blockers, plus Blocked and Help flags), Retrospective for sprint retros with formats like Start-Stop-Continue, Q&A as the team's private Stack Overflow, and a Wiki — Markdown with live GitHub-flavored preview, which is how engineers already write. If this is your team, the dedicated walkthrough is worth your time: Openbook for Software Teams.
Product. Product management sits between discovery and delivery, and this template reflects both halves: whiteboards for discovery work (story mapping and customer journey templates included), docs for specs and PRDs, a board for the roadmap-to-execution flow, and Project Status — standing questions, a goals board with RAG status, and narrative updates with history — for the stakeholder-facing layer. Product managers live or die by stakeholder communication; this template treats it as a first-class room, not an afterthought.
The company-level templates
Startup HQ. A whole small company in one space. When you are 8 people, you do not need six departmental spaces — you need one space where everything happens: a feed as the company square, a board for whatever is currently on fire, docs as the everything-drawer, events, time off, and a check-in rhythm. Startup HQ is the "just get us all in one place" template. The natural evolution: as the company grows past roughly 20–30 people, teams bud off into department spaces, and Startup HQ becomes the company-wide intranet space. That path is covered in Using Openbook as Your Company Intranet.
Single Project. Everything else on this list is organized around a team; this one is organized around an outcome. Spin it up at kickoff for a cross-functional effort — a launch, a migration, an event — and archive it when the work ships. The composition leans on time-bound tooling: Gantt for the timeline with milestones, dependencies, and critical path; a kanban board for execution; Project Status for the weekly written update; docs for decisions; and a Retrospective room waiting at the end for the post-mortem. Because the space is scoped to the project, membership is too — pull in exactly the people involved, from any department.
The client and support templates
Agency. Client delivery has a shape: brief in, work through stages, review, approval, report. This template composes for that shape — a board for deliverables, Proofing for the review-and-approval loop (time-coded annotations for video work, per-reviewer decisions for the paper trail), a dashboard for client-facing reporting, a feed for updates, and docs for scopes and briefs. The standard pattern is one Agency-template space per client, with the client invited under the Viewer or Member role and internal rooms hidden via per-room visibility. The full operating manual: Running an Agency on Openbook.
Support. Support teams run on two assets: a queue and answers. The queue is a board — requests as cards moving through triage, in-progress, and resolved. The answers live in Q&A and the wiki: Q&A for the long tail of "how do we handle X" with voting and accepted answers, the wiki for polished, stable reference. Check-ins keep a rotating team synchronized across shifts without a handoff meeting, and mood tracking matters more in support than almost anywhere — it is a burnout-prone job, and green-yellow-red trends surface trouble early.
Template vs blank: the honest decision
Should you ever start from a blank space? Sometimes. Here is the actual tradeoff.
Start from a template when:
- Your team matches or nearly matches one of the twelve. "Nearly" is fine; deleting one room and adding another takes a minute.
- You are rolling Openbook out to skeptics. A seeded, working space makes the case on sight in a way an empty one cannot.
- You are not sure what you need. Templates encode sensible defaults; disagreeing with a default teaches you what you actually want, which staring at a blank page does not.
Start blank when:
- Your composition is genuinely unusual — a community organization that needs only Groups, Events, and a Feed; a review-only space that is just Proofing and Chat.
- You are an experienced Openbook admin building your fifth space and you already know the exact three rooms you want. At that point the template's head start is smaller than your own.
- You are creating a narrow utility space — say, a single shared board between two teams — where any extra room is noise.
The failure mode to avoid is not "wrong template." Templates are cheap to correct. The failure mode is blank-space paralysis: a space that stays empty for two weeks while its creator researches the perfect composition, and a team that forms its first impression on that emptiness. When in doubt, template.
Customizing after the click
The template's job ends the moment the space exists. Yours begins. A practical customization pass, in order:
- Prune. Delete any room your team will not touch in the first two weeks. Fewer, busier rooms beat a full sidebar of quiet ones. You can re-add any room type later in seconds.
- Rename. Rooms should be named for function, in your team's vocabulary: "Sprint Board," "Team Handbook," "Client Reviews" — not room-type names. If your team calls retros "sprint reviews," name the room that.
- Reorder the sidebar. The space sidebar is customizable. Put the daily-use rooms at the top — feed, then the main work board — and the periodic rooms (retros, time off) below.
- Set visibility. Apply per-room visibility to anything sensitive before you invite anyone: hiring boards, leadership docs, internal rooms in client spaces. The roles and permissions model — Owner, Admin, Member, Viewer, plus per-room restriction — covers most real-world cases with very little configuration.
- Replace the seed content with real work. Starter content shows people how a room works; real content makes them come back. Put this week's actual tasks on the board, write one real doc, post a real announcement. Then invite the team — the seeding-before-inviting sequence in Getting Started with Openbook applies to every template on this page.
- Go deeper inside rooms. Templates exist at the room level too: ~40 for table boards, 36 for kanban boards, 36 check-in formats, 12 retro formats, 11 whiteboard canvases, 14 Gantt plans. When a provisioned room is the right type but the wrong shape, an in-room template usually gets you the rest of the way.
When your team spans two templates
Real teams are messier than template names. Growth sits between Marketing and Product. RevOps sits between Sales and Ops. A design-heavy product squad is Software with a Proofing habit. Three ways to handle the straddle, in order of preference:
Pick the template that matches the work you do most, then borrow rooms. A growth team that ships experiments all day is mostly a Product team; start there and add the Marketing rooms it misses — a content-calendar table board, a campaign dashboard. Borrowing a room takes seconds. This is the right answer 80% of the time.
Pick by pain, not by identity. If you cannot decide which template "is" your team, decide which complaint hurts most. A RevOps team drowning in untracked requests should start from Ops (queue-shaped) even if its business card says Sales. The template is scaffolding for the first month, not a department badge — nobody will remember which one you clicked.
Split into two spaces only when membership actually differs. Two templates are a reason for two spaces only if the two halves of the work involve meaningfully different people or different visibility needs — say, a Sales space the whole revenue org joins and a tighter Ops space for the systems team. If it is the same eight people either way, one space with a broader room set beats two spaces they have to hop between. Remember what stays shared regardless: one ⌘K search, one people directory, one permission model across every space in the organization.
And if the straddle is extreme — a team that is one-third each of three templates — that is the "start blank" case from earlier. Sketch five rooms on paper, build exactly those, and skip the template.
Did the template stick? A 30-day check
A template's job is to get a space adopted, so measure adoption, not aesthetics. Thirty days after launch, look at four signals:
- The anchor room has a pulse. Cards moved this week on the board, proofs reviewed, pipeline rows updated. If the anchor room is quiet, the space has not replaced whatever came before it — find out what the team is still using and either migrate it or delete the room that lost.
- The feed gets replies, not just posts. One-way feeds are notice boards; comment threads and reactions mean the team actually lives there. If it is one-way, the fix is usually leaders replying visibly, not more posting.
- The ritual runs without a reminder. The scheduled check-in gets answered, the retro happens, the status update ships. Rituals that need weekly nagging in month two should be redesigned — shorter, less frequent, or moved to a format the team prefers.
- Somebody asked for a room. The healthiest sign of all. "Can we get a whiteboard in here?" means the team has internalized composition — the space is theirs now, not the template's.
Then prune once more. Whatever the template provisioned that has no activity after 30 days, delete without ceremony. A space that shrinks to fit its team is succeeding; a space preserving unused rooms out of respect for the template is not.
Rolling out templates across a company
If you are the person bringing Openbook to a whole organization rather than one team, templates change your job from building workspaces to approving them. A rollout pattern that works:
- Week 1: one flagship space. Pick the team with the most obvious pain and the most energy. Use their department template, customize it with them, and make it good. This space is your demo.
- Weeks 2–3: self-serve with guardrails. Let the next teams pick their own templates. Your role is a 30-minute session per team on the customization pass above — prune, rename, visibility — not building for them. Teams keep spaces they shaped themselves.
- Week 4: the company space. Once a few team spaces are alive, add the company-wide space (Startup HQ's composition scales up well: feed, events, groups, Q&A, wiki). Announcements, birthdays via the feed's bulletin sidebar, and the people directory with org chart give the whole org a shared home.
- Ongoing: a light naming convention. "Team — Marketing," "Client — Acme," "Project — Q4 Launch." With multiple spaces, the ⌘K command palette plus predictable names means anyone can jump anywhere in two keystrokes.
Next steps
Templates compress the distance between "we should try this" and "our team works here." To put this guide to work:
- Pick your template — closest match wins, perfection not required — and create the space.
- Run the customization pass: prune, rename, reorder, set visibility, replace seed content with real work.
- Follow the first-week plan in Getting Started with Openbook to turn the space into a habit.
- When you outgrow the starting composition, Rooms Explained is the catalog of all 18 room types and the pairings that work.
One click gets you a working space. One editing pass makes it yours. The rest is showing up.