Use a project-based workspace for each active client or initiative, paired with one small cross-project hub for templates and shared files. Apply a consistent naming convention before you create a single task, and build one reusable project template today. Keep access minimal from the start: invite only the people who need to see a project, and mark sensitive work as private by default.
TL;DR:
- Using a project-based workspace per client enhances privacy and simplifies billing, especially for freelancers managing multiple clients.
- Consistent naming conventions with action verbs and clear deliverables improve team communication and streamline project setup.
- Regularly exporting project data at least once a month ensures portability and reduces dependence on a single vendor.
- Assigning roles carefully and marking sensitive projects private helps maintain confidentiality and control over client data.
- Importing tasks from spreadsheets requires standardizing columns and testing before full migration to avoid messy data and wasted time.
Table of Contents
- Choose the right workspace structure: project, team or cross-project hub
- Naming conventions and reusable templates
- Organise tasks and subtasks: boards, lists, tags and priorities
- Permissions, privacy and data control in shared workspaces
- Integrations and imports: getting your existing tasks into a workspace
- Maintenance and governance: archive, review and ownership
- Starter checklist and ready-to-use setup steps
- Author perspective: why privacy-first workspace design matters
- How Seven helps you implement these workspace best practices
- FAQ
- Sources
Choose the right workspace structure: project, team or cross-project hub
Most confusion in a shared tool comes from picking the wrong container for the work, not from a missing feature. There are three workable models, and your choice depends on how many clients, teams and recurring tasks you juggle.
- Project-based workspace: one workspace per client or initiative, ideal for freelancers and agencies that bill by project and need clean separation between clients.
- Team-based workspace: one workspace per internal team (marketing, operations), suited to a two-person team or small company running a handful of ongoing functions rather than discrete projects.
- Cross-project hub: a small shared space holding templates, brand assets and standard operating procedures, used alongside either model above, never as a replacement for it.
A freelancer juggling five clients should run five project-based workspaces, each with its own access list, so a client never sees another client's tasks. A two-person team might run a single team-based workspace with project boards inside it. A small agency often needs both: project-based workspaces per client, plus a cross-project hub for templates and internal admin. The trade-off is simple: more separation means better privacy and cleaner billing, but more workspaces to maintain.
Naming conventions and reusable templates
Vague task titles cost more time than any missing feature. Guidance on naming conventions recommends starting each task title with an action verb and naming the deliverable, because clarity about the expected outcome does more for team alignment than any platform choice.
- Name tasks as verb + deliverable + context, for example "Draft homepage hero section copy" rather than "Homepage".
- Name workspaces and projects as client, then project, then phase or sprint, for example "Acme, website redesign, sprint 2".
- Build one template project with your standard task list, labels and due date offsets, then duplicate it for every new client or sprint.
Pro Tip: Save your template as a locked copy and duplicate it rather than editing the original, so it never drifts from your standard.
Once the pattern is set, new project setup becomes copy, rename and assign, instead of rebuilding a task list from memory each time.
Organise tasks and subtasks: boards, lists, tags and priorities
The right view depends on how the work moves, not on personal preference. A board suits work that passes through visible stages (to do, in progress, review, done). A flat list suits short, linear projects with no real workflow stages. A list grouped by section suits ongoing operational work with recurring categories.
- Use boards for client deliverables that move through stages and benefit from a visual status check.
- Use flat lists for simple projects with fewer than roughly twenty tasks and no meaningful stage changes.
- Break any task with more than one owner or more than one deliverable into subtasks, each with its own owner and due date.
- Apply tags or custom fields for things you will want to filter later: client, priority, billable status.
- Set a priority or status field on every task so a weekly review can filter to what is overdue or urgent without opening each task.
Tags and priorities only earn their keep if you use them consistently. A tag applied to three tasks out of three hundred is not a filtering system, it is clutter.
Permissions, privacy and data control in shared workspaces
Access control is the part of workspace setup most teams skip, and it is the part that matters most once a workspace holds client data. Set roles deliberately rather than inviting everyone as an editor by default.
- Give owner access only to the person accountable for the whole project.
- Give editor access to anyone actively completing tasks inside it.
- Give viewer access to stakeholders who need visibility but should not change structure or due dates.
- Mark sensitive or client-confidential projects private, visible only to the people explicitly added, rather than visible to the whole workspace by default.
Running a periodic export is one of the simplest ways to confirm you can move or back up your project data without depending on the vendor, a habit worth building into any privacy-focused setup (product guidance on export tests). Decide workspace-level permissions first (who can even see the workspace exists), then project-level permissions inside it, and recheck both whenever someone leaves the team.
Integrations and imports: getting your existing tasks into a workspace
Most teams migrate from a spreadsheet, and the way you prepare that spreadsheet decides whether the import is clean or a mess you spend a week untangling.
- Standardise your column names first: task title, assignee, due date, status, priority, in that exact order.
- Map each assignee name to the exact name or email used in the destination workspace, since mismatches create orphaned tasks.
- Set dates in a single consistent format throughout the sheet before importing.
- Run a small test import of ten to twenty rows and check titles, assignees and dates landed correctly before importing the rest.
- Once tasks are in, attach relevant files directly to each task and move related discussion into the workspace's built-in messaging, so files and conversation stay with the work instead of scattered across email.
A clean five-minute test import beats a one-shot import of a thousand rows you have to manually fix afterwards.
Maintenance and governance: archive, review and ownership
A workspace that nobody maintains slowly fills with stale tasks and forgotten access grants, and that is where privacy risk creeps in.
- Run a weekly check: close finished tasks, flag anything overdue, confirm nobody left mid-project still has access.
- Run a monthly audit: review every active workspace's member list, remove anyone who no longer needs access, and check private projects are still marked private.
- Archive a project once it is complete rather than deleting it, so it is out of daily view but can be restored if a client returns or a dispute needs the record.
- Assign one workspace owner per workspace, responsible for the audit and for running the periodic export.
A simple monthly rhythm, paired with one named owner per workspace, keeps clutter and access risk low without turning governance into a full-time job.
Starter checklist and ready-to-use setup steps
Work through this once and every new project after it takes minutes, not hours.
- Create the workspace and apply your naming template to the project and its first tasks.
- Import existing tasks from a spreadsheet, or create the initial task list manually using your verb-plus-deliverable pattern.
- Set permissions: assign an owner, invite only the people who need access, and mark the project private if it holds confidential client work.
- Run a small test import if you migrated data, then run a full export to confirm you can retrieve everything cleanly.
- Confirm every core team member can see what they need and nothing more before you start active work.
Author perspective: why privacy-first workspace design matters
Most project management advice treats structure as a productivity question. It is also a privacy question. A workspace with loose permissions and no export habit is not just messy, it is a liability waiting for a client dispute or a departing contractor to expose. The teams that get this right treat naming conventions and access lists as seriously as deadlines, because both determine whether your project data is actually yours.
— Greg
How Seven helps you implement these workspace best practices
We built Seven around exactly the structure this guide recommends: flexible workspaces you can split by project, team or client, with built-in messaging and file attachments so discussion and documents never leave the workspace. 
Importing an existing task list takes minutes with our Excel import, and because we never mine your data or sell it for analytics, the export test above works the way it should: a full copy of your data, with no lock-in. Plans start at $5 AUD a month for individuals and $9 AUD a month per seat for teams, both on our pricing page, after a 7-day free trial.
FAQ
What is the best workspace structure for a freelancer?
A project-based workspace per client works best for most freelancers, since it keeps each client's tasks and files fully separate. Add a small cross-project hub for templates and recurring admin so you are not rebuilding task lists for every new client.
How should I name tasks and projects consistently?
Name tasks with a verb followed by the deliverable and context, such as "Draft homepage hero section copy", because this pattern makes the expected outcome explicit to anyone on the team (naming convention guidance). Name workspaces and projects as client, then project, then phase, for example "Acme, website redesign, sprint 2".
How often should I export my project data?
Run a full export at least once a month as part of your maintenance routine, and always immediately after a major restructuring of a workspace. This confirms your data is portable and that you are not dependent on any single vendor to keep working.
Should every team member have editor access?
No, assign owner access only to the person accountable for the project, editor access to people actively completing tasks, and viewer access to stakeholders who just need visibility. Review this list monthly and remove access for anyone who has left the project.
Can I import an existing spreadsheet of tasks into a new workspace?
Yes, standardise your column names and date formats first, then run a small test import before importing the full list. Our platform's Excel import is built for this kind of migration.
Sources
For a closer look at the naming principles behind clearer task titles, see the Lean Six Sigma guidance on project naming. To see flexible workspace design and the export test in practice, read Run the Export Test: Flexible Workspaces for Project Managers. For a visual-boards example of how teams commonly structure daily workflow, see Managing Daily Team Workflows Visually with Trello. For governance and expense-tracking cadence ideas that pair well with the maintenance schedule above, see the 30/60/90 day project expense tracking plan.
- Define phase: creating effective project names and descriptions in Lean Six Sigma