ClickUp Ways of Working
Purpose
The single doorway for every Symphony Core team member who creates, updates, or reviews tickets in ClickUp. Captures the rules and habits that make our workspace coherent: status hygiene, client identification, evidence, time tracking, tags, subtasks, assignment, views, and where each rule's authoritative source lives.
This is the breadth layer. Each section is short and points to the depth layer (the canon — SOPs, standards, working rules) when you need the full text.
Scope and audience
- For: Team Members — everyone who interacts with ClickUp as a user (anyone creating, updating, reviewing, or commenting on tickets).
- Not for: workspace admins doing space/folder/list provisioning — that's SC Task Management Workspace Setup SOP and ClickUp SC Operations Space Setup SOP.
Recommended reading order for new joiners
- This document end-to-end (~20 min).
- Markdown Task File to ClickUp SOP — how tickets are authored.
- SC Contractor Task Quality — Pre-Work Standard — what makes a ticket reviewable.
- SC Contractor Task Quality — Review Standard — how reviewers act on completed work.
- ClickUp Views and Filters Guide — building and using saved views.
- ClickUp Timesheet Approval SOP — if you log billable time.
Roles
Every ClickUp ticket is touched by up to four roles. Two are per-ticket; two are workspace-wide. Each role may be filled by a human or by an AI agent where noted.
| Role | Per-ticket or workspace | Who | What they do |
|---|---|---|---|
| Creator | per-ticket | Human (Account Manager, Workspace Owner, contractor) OR AI (Claude when authoring tickets from a markdown task file) | Authors the ticket. Owns the description, acceptance criteria, Evidence bullet, tags, and initial routing (list, priority, assignee). The Creator is the one accountable for the ticket being well-formed at creation — see Pre-Work Standard. |
| Assignee | per-ticket | Human (one — see §8 single-assignee rule) | Owns execution. Logs time, advances status, attaches Evidence, completes the work. Exactly one per ticket; if two people need to act, that's two subtasks. |
| QA Reviewer | per-ticket (when present) | Human (default: the Account Manager) OR AI (Claude when reviewing markdown-defined deliverables) | Verifies that the work actually meets the acceptance criteria + Evidence bullet before the ticket can close. For client-facing tickets, this role is materialized as a qa-review-<parent-slug> subtask (see §7) and the parent cannot move to complete until the QA-Review subtask is closed. For internal/non-client tickets, the role is optional — self-attestation at close suffices and the AM samples post-hoc per the Review Standard. |
| ClickUp Admin | workspace-wide | Human (Workspace Owner) | Owns workspace configuration: ClickApps, status templates, custom fields, space/folder/list structure, tag taxonomy, member/guest permissions, automations. Orthogonal to the per-ticket triple — the Admin does not act on individual tickets in this role. See SC Task Management Workspace Setup SOP. |
Specialization: the timesheet approval flow uses QA Reviewer as the role-holder who reviews submitted timesheets for billing — see ClickUp Timesheet Approval SOP §3. Same role, narrower deliverable (the timesheet itself).
Legacy naming: before 2026-06-14 the per-ticket QA role was called the "AM-review subtask" because the AM was the default human. Existing am-review-* subtasks stay valid as-is (backward-compatible); new tickets use the qa-review-<parent-slug> name and treat the AM as the default-but-not-only-possible QA Reviewer.
1. Meta-principle: rules first, automation second
Every ClickUp Automation must enforce a rule that is already documented in canon — the documented procedures: this playbook, a SOP, a standard, or a working rule. New rules land in writing before any automation is built or changed. Don't infer rules from observed automation behavior — automation is downstream of writing, never the other way around.
Why this matters. Automation that encodes undocumented rules creates shadow policy: no one can read what the system is actually enforcing. The rule is the contract; the automation is a derivative of the contract.
In practice.
- See a behavior you don't understand and someone says "the automation does that" → push back. Ask which doc the rule lives in. If it doesn't live anywhere, the rule needs to be written before the automation continues to run.
- Want to propose a new automation? Write the rule first in the relevant canon doc (often this playbook). Open a separate change to add the automation referencing that rule.
- This applies symmetrically to ClickUp Automations, GHL workflows, and symphony-flow triggers.
See working rule rules-first-automation for the durable form of this rule.
2. Status invariants
Canonical status definitions live in SC Task Data Standard §1. Don't re-state them here; do internalize the invariants below — these are the rules that catch the failure modes we've actually seen.
The five statuses
TODO → IN PROGRESS → COMPLETE, with BLOCKED and CANCELLED as off-ramps.
Invariant 1 — time logged means the work has started
A task with non-zero
Time Trackedcannot remain inTODO. Logging the first time entry (live timer or manual entry) implies the work has started; the status must advance toIN PROGRESSin the same motion. If the work is already done, go straight toCOMPLETEwith the Evidence bullet satisfied.
Worked example. A task in Client Delivery > acme > active-work shows status TO DO but has 3h 45m of tracked time on it. Wrong state. The person who logged the time owns the fix: bump to IN PROGRESS (or COMPLETE if the work is done) before the next status sweep.
Why it matters. Status drives every saved view, dashboard, and reporting cut. If status lies, the views lie. The weekly timesheet approval pass treats any TO DO with time on it as an anomaly — fix in flight, not at month-end.
Invariant 2 — BLOCKED needs a blocked-on:* tag
A task in
BLOCKEDstatus must carry one of theblocked-on:client,blocked-on:vendor, orblocked-on:hosting-supporttags (see SC ClickUp Tag Taxonomy §External-dependency state). The tag names what we're waiting on — status alone doesn't.
Invariant 3 — QA-Review subtask gates parent completion
A parent task that carries a
qa-review-<parent-slug>subtask (or the legacyam-review-<parent-slug>form) cannot move toCOMPLETEuntil the subtask itself is closed. See Markdown Task File to ClickUp SOP §3c. Role: QA Reviewer (see §Roles).
Per-client folder architecture (where tasks live)
Each active client gets one folder under Client Delivery. Each folder has two lists:
active-work— every task in every status; the Closed-group hide oncompletekeeps finished work out of default views.reference— standing reference items only, never work in flight.
Cold storage uses ClickUp's native task archive on a monthly UI sweep — see Workspace Setup SOP §5.6.
3. Client identification — tag vs custom field
We use both a client/<slug> tag and a Client custom field. They have orthogonal jobs:
| Where the task lives | Use this | Why |
|---|---|---|
Client Delivery > <slug> > active-work (per-client list) | Client custom field is canonical; client/<slug> tag is optional | Field gives dropdown integrity and powers the "By Client" view |
Client Delivery shared list (e.g., client-delivery-operations) | Both: Client field and client/<slug> tag | List doesn't encode the client; tag carries it for cross-space reports |
SC Operations space (touching a client) | client/<slug> tag (field doesn't exist here) | Tag is the only client identifier available in SC Operations |
Drift rule: when both are populated on a task, the tag slug must equal the Client field value. No drift.
Authoritative sources:
- SC ClickUp Tag Taxonomy §Client identity
- SC Task Management Workspace Setup SOP §5.3
- working rule
client-identifier-discipline
4. Acceptance criteria and the Evidence bullet
Every closeable ticket has acceptance criteria. The last AC bullet names the concrete artifact attached at close — screenshot, deploy URL, log link, PR URL.
Evidence: screenshot of the updated header in the staging env attached to this ticket
Blocking for client-facing tickets; advisory for internal work. Without the Evidence bullet, validation reduces to "the contractor said so." See pre-work standard validation-evidence-rule.
5. Time tracking
Applies to anyone billing hours through ClickUp (currently Project Partner vendor teams; SC Internal Team Members stay on Google Sheets per Timesheet and Invoice Submission SOP).
- Native ClickUp timer or manual entry with explicit start/end. Either is fine.
- One task per entry. If you switched tasks mid-session, that's two entries.
- Description required on every entry.
Built header CTA + applied design-system classis good;WP workis not. - 0.1-hour granularity (6-minute increments). Decimal hours, not clock minutes.
- End-of-day batch logging is fine; end-of-week is not — descriptions get vague and entries become unverifiable.
- First time entry on a
TO DOtask → bump toIN PROGRESSin the same motion (loop back to §2 Invariant 1).
Full submission flow and AM approval mechanics: ClickUp Timesheet Approval SOP. Per-contractor companions live at 10-people-operations/contractors/<contractor>/<contractor>-timesheet-quickstart.md.
6. Tag hygiene
The space-level tag list is a closed taxonomy. Only tags listed in the SC ClickUp Tag Taxonomy are valid on tickets. New tags require a PR amending the taxonomy before they appear in ClickUp.
Quick reference for the families:
| Family | Use |
|---|---|
client/<slug> | Client identity (see §3) |
domain:* | Subject-matter area (wordpress, seo, dns, billing, ghl, design) |
quality:rework / :escaped / :partial-met | Defect telemetry — applied per review standard |
blocked-on:* | External dependency causing a BLOCKED status (see §2 Invariant 2) |
What is not a tag: status, priority, assignee, due date, time estimate, one-off context. Use the structured field or the description.
7. Subtasks and the QA-Review pattern
For any ticket whose primary output is client-facing (published copy, brand assets, anything the client will see), the Creator adds a qa-review-<parent-slug> subtask at ticket creation. The subtask follows the standard flow (to do → in progress → complete). The QA Reviewer (default: the Account Manager — see §Roles) is the assignee.
The parent ticket cannot move to complete until the QA-Review subtask is closed (§2 Invariant 3). This is how SC catches defects pre-client without a workflow-wide review status.
Internal/non-client work flows TODO → IN PROGRESS → COMPLETE on contractor self-attestation backed by the Evidence bullet. Post-hoc sampling by the AM catches escapes across both paths.
Legacy compatibility: before 2026-06-14 this pattern was named am-review-<parent-slug>. Existing am-review-* subtasks remain valid (do not rename them retroactively). New tickets use qa-review-*. Views must match both — see Views Guide §6.5.
Full mechanics: Markdown Task File to ClickUp SOP §3c.
8. One assignee per ticket
Tickets have one assignee. Multiple assignees split accountability and break "who owns this" — they're disabled at the workspace level. If two people need to act, that's two subtasks or two separate tickets, not one ticket with two assignees.
See working rule single-assignee-per-ticket.
9. Views and saved filters
Use the saved views; don't rebuild ad-hoc filters in the UI every week.
| View | Recipe | Use |
|---|---|---|
workspace-all-open | Views Guide §6.7 | Every open ticket across every client — the daily situational-awareness view |
workspace-completed-30d | Views Guide §6.8 | What closed in the last 30 days; also the surface for the monthly native-archive sweep |
<client>-completed-this-month | Views Guide §6.9 | Per-client completed work for the current calendar month |
timesheet-<contractor-slug> | Views Guide §6.1 | Per-contractor time-entry export |
active-work-<client-slug> | Views Guide §6.2 | Per-client open work, sorted by priority/due-date |
blocked-all-clients | Views Guide §6.3 | Cross-client blocked-ticket triage |
quality-flagged-15d | Views Guide §6.4 | Quality-tagged tickets in the rolling 15-day window |
qa-review-queue | Views Guide §6.5 | Personal QA-Review subtask queue (matches both qa-review-* and legacy am-review-*) |
capacity-next-7d | Views Guide §6.6 | Workload check for the upcoming week |
Naming convention and sharing rules are in Views Guide §5 and §4. If you find yourself rebuilding the same filter twice, save it under the convention. Avoid list-name filters — see Views Guide §2 anti-pattern note.
10. Comments vs description
| Where | What goes there |
|---|---|
| Description | Current-state snapshot of the ticket: scope, acceptance criteria, links to canon. Updated as the work evolves — not just at creation. |
| Comments | Audit trail of discussion, decisions, blockers, hand-offs, client quotes. Append-only by nature. |
Status changes don't replace description updates. If the AC changed mid-flight, edit the description and drop a comment naming what changed and why. The description should always read as if you're starting today.
11. Where to learn more
| Topic | Canon |
|---|---|
| Status model | SC Task Data Standard §1 |
| Tag taxonomy | SC ClickUp Tag Taxonomy |
| Ticket authoring | Markdown Task File to ClickUp SOP |
| Time tracking + approval | ClickUp Timesheet Approval SOP |
| Workspace/space setup | SC Task Management Workspace Setup SOP |
| SC Operations space | ClickUp SC Operations Space Setup SOP |
| Pre-work quality (AC, evidence, tags) | Pre-Work Standard |
| Review quality (quality tags, sampling) | Review Standard |
| Views and filters | ClickUp Views and Filters Guide |
| Ticket template | ClickUp Thin Ticket Template |
| Durable behavioral rules | .claude/working-rules.md |
Revision History
| Date | Version | Change | Author |
|---|---|---|---|
| 2026-06-08 | 1.0 | Initial consolidated playbook. Captures the meta-principle (rules first, automation second), status invariants (including the new Time Tracked > 0 ⇒ ≥ IN PROGRESS rule from sc-task-data-standard §1), client identification, AC + evidence, time tracking, tag hygiene, AM-review subtasks, single assignee, views, and comments-vs-description. Designed as the single doorway for every internal-team user. | Symphony Core Systems Team |
| 2026-06-08 | 1.1 | §2: added "Per-client folder architecture" sub-section reflecting the 2-list simplification (active-work + reference, no completed-work or archive lists). §9 Views: rewrote as a table naming the three new workspace/folder views (workspace-all-open, workspace-completed-30d, <client>-completed-this-month) alongside the existing recipes, with a pointer to the list-name anti-pattern note. Driven by Workspace Setup SOP v1.2. | Symphony Core Systems Team |
| 2026-06-12 | 1.2 | Sprint 1 of Rohit's Remarkable-tablet feedback: §Scope wording → "Team Members"; §1 canon defined inline on first use; §2 Per-client folder architecture sub-section: removed historical commentary (the "retired 2026-06-08 because…" sentence), describes current state only; §5 Time tracking: "individual retained contractors" → "SC Internal Team Members"; §9 Views table: quality-flagged-this-quarter → quality-flagged-15d. Driven by 2026-06-12 sprint backlog S1-2 through S1-5. | Symphony Core Systems Team |
| 2026-06-14 | 1.3 | Sprint 2: new §Roles section (4-role model — Creator / Assignee / QA Reviewer / ClickUp Admin, Human-or-AI annotations). §2 Invariant 3 + §7 renamed AM-review subtask pattern → QA-Review subtask pattern; subtask name becomes qa-review-<parent-slug> for new tickets, existing am-review-* stay legacy. §9 view name am-review-queue → qa-review-queue. workflow_owner: CEO → workflow_owner: Workspace Owner (per reference-roles-strictly). Driven by 2026-06-12 backlog S2-1 + S2-4. | Symphony Core Systems Team |