Almost every conversation starts the same way:<\/p>\n\n\n\n
\u201cWe need you to fix our ClickUp.\u201d<\/p>\n\n\n\n
But here\u2019s the thing I\u2019ve learned after years of implementation work: cClickUp<\/a> is almost never the problem. The problem is usually that there are no clear rules for how services are delivered, so everyone makes things up as they go.<\/p>\n\n\n\n That\u2019s the shift this workflow is built to solve.<\/p>\n\n\n\n In this article, I\u2019ll show you how I use Custom Fields<\/a> by task type in ClickUp<\/strong> to separate project-level context from task-level action, keep client delivery clean, and build a dashboard I actually trust.<\/p>\n\n\n Growth exposes weak delivery systems.<\/p>\n\n\n\n A founder told me this recently in a way I haven\u2019t stopped thinking about:<\/p>\n\n\n\n \u201cI need to get this agency to a point where we can responsibly grow from 30 to 40 or 50 clients without everything falling apart.\u201d<\/p>\n\n\n\n That is the real goal.<\/p>\n\n\n\n Not a prettier workspace. Not more statuses. Not more dashboards for the sake of dashboards.<\/p>\n\n\n\n The goal is responsible growth.<\/p>\n\n\n\n But many service businesses hit the same wall:<\/p>\n\n\n\n This creates a scavenger hunt.<\/p>\n\n\n\n When someone asks, \u201cWhere is the contract?\u201d or \u201cIs this in scope?\u201d or \u201cWhat do I need to work on this week?\u201d, the answer should not require five tools, three Slack threads, and one tiny existential crisis.<\/p>\n\n\n\n The fix starts with clear structure.<\/p>\n\n\n\n I\u2019m Jacqui Myslinski, an Operations Architect who helps founders of B2B service businesses figure out why client delivery feels harder than it should.<\/p>\n\n\n\n I spent four years implementing ClickUp before I had a major \u201caha\u201d moment: for every company that says they need ClickUp fixed, there are usually deeper operations issues to uncover first.<\/p>\n\n\n\n That realization completely changed how I work.<\/p>\n\n\n\n Now, I help established service-based businesses find what is breaking inside client delivery, define the rules for how work should happen, and design systems that support growth without imploding.<\/p>\n\n\n\n I\u2019m also a recovering perfectionist, process junkie, and productivity nerd. So yes, I love a good dashboard. But only if the data underneath it is actually useful.<\/p>\n\n\n\n When client delivery starts to feel messy, teams often blame the tool.<\/p>\n\n\n\n I get it. If your tasks are outdated, dashboards feel wrong, and nobody trusts the workspace, it\u2019s tempting to say the tool is broken.<\/p>\n\n\n\n But in most cases, the tool is showing you the real problem: the way work happens hasn\u2019t been defined clearly enough.<\/p>\n\n\n\n If there are no rules for how services are delivered, everyone fills in the gaps differently. That means:<\/p>\n\n\n\n At that point, ClickUp isn\u2019t the problem. ClickUp is just where the lack of operating rules becomes visible.<\/p>\n\n\n\n That\u2019s why I don\u2019t start by adding more features. I start by separating what belongs at the project level from what belongs at the task level.<\/p>\n\n\n\n ClickUp Custom Fields let you add structured information to tasks, Lists, Folders, and Spaces. You can track details like service type, client contact, project phase, tech stack, estimated hours, contract link, or work category.<\/p>\n\n\n\n ClickUp Task Types<\/a> let you define different types of work inside your workspace. That matters because not every task needs the same information.<\/p>\n\n\n\n A client project needs big-picture context. A client task needs execution details.<\/p>\n\n\n\n When you combine Custom Fields with Task Types, you can show the right information at the right level of work. That keeps your workspace cleaner and makes it easier for the team to know what belongs where.<\/p>\n\n\n\n For my client delivery workflow, I use two main Task Types:<\/p>\n\n\n\n That separation is what makes the whole system work.<\/p>\n\n\n\n Before I show you my workflow, let\u2019s talk about what usually goes wrong.<\/p>\n\n\n\n Imagine a workspace where the parent task is a full project. It has useful fields like budget, cost, delta, due date, phase, and owner. So far, fine.<\/p>\n\n\n\n But then you open a subtask like \u201cReview the safety management plan,\u201d and all those same fields are still sitting there.<\/p>\n\n\n\n Now the person doing the work has to stop and think:<\/p>\n\n\n\n That is how workspaces become noisy.<\/p>\n\n\n\n People don\u2019t trust the system because the system asks them for information that doesn\u2019t belong there.<\/p>\n\n\n\n This is why I like Custom Fields by task type. The goal is simple: show people what they need, when they need it, where they need it.<\/p>\n\n\n\n The efficiency is in the simplicity.<\/p>\n\n\n The biggest fix in my workflow was separating project context from task-level action.<\/p>\n\n\n\n A project and a task have different jobs.<\/p>\n\n\n\n A project should answer the big-picture questions. A task should tell someone what to do next.<\/p>\n\n\n\n That sounds obvious, but most messy workspaces ignore it.<\/p>\n\n\n\n My delivery workflow uses two Task Types:<\/p>\n\n\n\n That one distinction changes the experience for everyone.<\/p>\n\n\n\n The project holds the context. A client project should answer the questions I need at a glance.<\/p>\n\n\n\n For my actual client delivery workflow<\/a>, the project-level task includes fields like:<\/p>\n\n\n\n This is the information I need as the project manager.<\/p>\n\n\n\n For example, when I\u2019m helping a company implement ClickUp, ClickUp is rarely the only tool they use. I need to know whether they are using Google Workspace<\/a>, Microsoft products, Dropbox, Salesforce, HubSpot, Teams, or Outlook.<\/p>\n\n\n\n I used to forget and ask again. That felt ridiculous. So now I keep the tech stack at the project level.<\/p>\n\n\n\n The same goes for scope.<\/p>\n\n\n\n If a client asks for something extra and I can\u2019t remember whether it\u2019s included, I don\u2019t go digging through emails. I open the project, click the roadmap or contract URL, and get the answer in seconds.<\/p>\n\n\n\n That one field saves me from a full scavenger hunt.<\/p>\n\n\n Tasks should focus on execution.<\/p>\n\n\n\n A client task should tell me:<\/p>\n\n\n\n That\u2019s where ClickUp Tasks, Custom Fields, and Task Types work together.<\/p>\n\n\n\n Instead of overloading every item with every possible field, I tailor the fields based on the type of work being done.<\/p>\n\n\n\n This gives the team a cleaner experience. It also makes the workspace much easier to maintain as client volume grows.<\/p>\n\n\n\n The real value of this setup is that ClickUp becomes the index for the rest of the work.<\/p>\n\n\n\n A lot of operational chaos comes from one simple problem: information exists, but it is scattered across too many tools<\/a>.<\/p>\n\n\n\n Maybe the contract lives in a proposal tool. Maybe supporting docs are in Google Drive. Maybe deal details sit in HubSpot. Maybe context is buried<\/a> in a message thread nobody wants to revisit.<\/p>\n\n\n\n Rather than pretending those tools don\u2019t exist, I connect them back to the project in ClickUp.<\/p>\n\n\n\n That way, ClickUp becomes the place I start.<\/p>\n\n\n\n Here\u2019s what that unlocks:<\/p>\n\n\n\n ClickUp is the hub. It\u2019s the index for everything that happens around the work.<\/p>\n\n\n\n That\u2019s the difference between having tools and having an operating system. When the links, fields, and standards are built intentionally, ClickUp doesn\u2019t compete with the rest of your stack. It organizes it.<\/p>\n\n\n\n A client delivery hub works best when people can answer routine questions without asking around.<\/p>\n\n\n\n For me, that means roles, tags, and links need to be visible where the work happens.<\/p>\n\n\n\n At the project level, I want to see the delivery team immediately:<\/p>\n\n\n\n This helps me understand who is working on the engagement without opening five subtasks.<\/p>\n\n\n\n It also supports automations and agents later. If the project-level roles are clear, subtasks can be assigned more easily based on the type of work.<\/p>\n\n\n\n Tags help me organize my own execution work<\/a>.<\/p>\n\n\n\n My personal workflow includes a tag I add once a task is truly ready to be worked on. That tag also categorizes the type of work.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n If I have four configuration builds to do, I can group them together. If I need to prep for meetings or answer client questions, I can batch that work too.<\/p>\n\n\n\nWhen Growth Makes Client Delivery Feel Heavier<\/h2>\n\n\n\n
\n
About Me: Operations Architect and Productivity Nerd<\/h2>\n\n\n\n
Why \u201cFix Our ClickUp\u201d Is Usually the Wrong Diagnosis<\/h2>\n\n\n\n
\n
New to Custom Fields by Task Type in ClickUp?<\/h2>\n\n\n\n
\n
The Bad Example: When Every Task Carries Every Field<\/h2>\n\n\n\n
\n
![\"](\"https:\/\/clickup.com\/blog\/wp-content\/uploads\/2026\/04\/Screenshot-2026-05-01-at-1.39.09-AM-1400x783.png\")
My Fix: Separate Client Projects From Client Tasks<\/h2>\n\n\n\n
\n
The task holds the action.<\/p>\n\n\n\nWhat belongs on a client project<\/h3>\n\n\n\n
\n
![\"Project](\"https:\/\/clickup.com\/blog\/wp-content\/uploads\/2026\/04\/Screenshot-2026-05-01-at-1.43.55-AM-1400x783.png\")
What belongs on a client task<\/h3>\n\n\n\n
\n
How ClickUp Became the Index for My Client Delivery Work<\/h2>\n\n\n\n
\n
How I Use Roles, Tags, and Links to Stop the Scavenger Hunt<\/h2>\n\n\n\n
\n
\n
![\"Action](\"https:\/\/clickup.com\/blog\/wp-content\/uploads\/2026\/04\/Screenshot-2026-05-01-at-1.46.37-AM-1400x783.png\")
![\"ClickUp](\"https:\/\/clickup.com\/blog\/wp-content\/uploads\/2026\/04\/Screenshot-2026-05-01-at-1.50.11-AM-1400x783.png\")