Skip to main content

SC ClickUp Tag Taxonomy

Purpose​

Names every approved space-level ClickUp tag, what it means, when to apply it, and who applies it. The taxonomy is strict: tags not listed here are not allowed on tickets, and new tags require a PR amending this doc before they are applied.

Without governance, ClickUp tag drift produces a tag list that grows monotonically — synonyms accumulate, abandoned tags clutter pickers, and reporting becomes unreliable. A short, curated taxonomy keeps tags useful as a telemetry surface (per-contractor quality patterns, per-domain throughput, per-blocker latency).

Scope​

  • In scope: Space-level tags applied to ClickUp tasks in the Client Delivery and SC Operations spaces.
  • Out of scope: Repo doc frontmatter tags (see SC Tagging Standard §Core Tag Categories); GHL contact tags (see SC Tagging Standard §GHL Contact Tags & Custom Fields).

Governance rules​

  1. Closed taxonomy. Every tag on every ticket must appear in §Approved tags below. Ad-hoc tags are not allowed.
  2. New tags require a PR. To add a tag, open a PR amending this doc with: name, definition, when applied, who applies, automation implications. Land the PR before applying the tag in ClickUp.
  3. Quarterly audit. Each quarter the CEO or designated AM lists all space-level tags in the ClickUp UI, diffs against this doc, removes or renames orphans, and posts a one-paragraph summary as a comment on the recurring audit task. See §Quarterly audit procedure for the checklist.
  4. Tag format:
    • Lowercase, hyphen between words.
    • Use a colon (:) prefix to namespace categories: quality:rework, domain:wordpress, blocked-on:client.
    • Exception: client tags use a forward slash (client/<slug>) to match the existing repo frontmatter convention from SC Tagging Standard.
  5. Tags are not structured fields. Status, priority, assignee, due date, time estimate are ClickUp fields, not tags. Tags are reserved for metadata that doesn't fit a structured field.

Approved tags​

Client identity​

  • client/<slug> — identifies the client the task serves. Slug matches the directory name under 09-clients/ in the documentation repo.
    • Required on: SC Operations tasks that touch a client (SC Operations has no Client custom field — the tag is the only client identifier there); Client Delivery tasks in shared lists that don't encode the client (e.g., client-delivery-operations, reference).
    • Optional on: Client Delivery tasks inside a per-client list (e.g., Client Delivery > <slug> > active-work). In those lists the Client custom field (see SC Task Management Workspace Setup SOP §5.3) is the canonical in-space identifier; adding the tag on top is redundant but not forbidden.
    • Tag–field correspondence: when both the tag and the Client custom field are populated on the same task, the tag slug must equal the Client field value. No drift between the two.
    • Example: client/acme, client/acme-hvac.
    • Applied by: task author at creation.
    • Automation: future symphony-flow reporting filters by this tag for per-client throughput across both spaces — the tag is the only client identifier that works in SC Operations, so it remains the canonical cross-space rollup key.

Domain area​

What subject-matter area the task touches. Use to filter for skill matching and reporting.

  • domain:wordpress — WordPress builds, plugin work, theming.
  • domain:seo — SEO audits, on-page optimization, SearchAtlas configuration, sitemap work, GSC integration.
  • domain:dns — DNS records, domain transfers, cutover coordination.
  • domain:billing — invoicing, subscription configuration, payment reconciliation.
  • domain:ghl — GHL sub-account configuration, workflows, snapshots, custom fields.
  • domain:design — visual design, brand assets, Canva/Figma work.
  • domain:docs — documentation work in the repo or Drive: SOP edits, README updates, standards changes, template authoring, lead/client profile maintenance.

Add new domain:* tags via PR when a new area recurs across 3+ tasks. One-off domains do not justify a tag.

Sales pipeline stage​

Mirrors the five open stages of the Symphony Core Sales Pipeline. Applied to tickets in the Sales folder (under SC Operations) so per-stage throughput and bottlenecks are filterable. The corresponding closed states (Closed Won, Closed Lost) are represented by ClickUp status, not by tag — tags persist as a history surface, but the open/closed boundary belongs to status.

  • sales:new-lead — initial capture, awaiting qualification.
  • sales:discovery — discovery call and needs assessment phase.
  • sales:proposal-sent — proposal delivered, awaiting evaluation.
  • sales:follow-up — active follow-up and negotiation post-proposal.

A ticket carries one sales:* tag at a time, updated as the stage advances (remove the prior tag, add the new). The same ticket's tag history reconstructs the engagement's pipeline journey when combined with the ClickUp activity log.

Applied by: lead owner at creation; updated by lead owner or AM as stage progresses.

Quality (defect telemetry)​

Applied to tasks that did not meet AC the first time, or that closed cleanly but produced a defect in the wild. The whole family persists on the task across reopens — the audit trail matters more than visual cleanliness.

  • quality:rework — Task was sent back for a defect found during the AM-review subtask (client-facing deliverables only) before the work reached the client. AC was not met, the deliverable broke a side-effect, or the work did not match the spec. Applied at the moment the parent task is moved back to in progress. Remains on the task permanently, including after re-close.
    • When NOT to apply: advisory feedback only (see Review Standard §Feedback tone). Rework is for blocking defects, not nice-to-haves.
    • Distinguished from quality:escaped: rework = caught by internal AM-review subtask pre-client; escaped = caught after release to client or in production (typically via post-hoc sampling).
    • Applied by: Account Manager.
  • quality:escaped — Task was closed cleanly and the defect was discovered later — in production, by the client, by a downstream task, or during post-hoc sampling. The "oversight" case. Applied either on reopen of the original task, or as a tag on a follow-up task that links back to the original via the description.
    • When to apply: any time work that previously closed turns out to have been wrong, incomplete in a way the AC should have caught, or built on a faulty assumption — including defects surfaced during weekly post-hoc sampling (see Review Standard §Post-hoc sampling). The bar is "would this defect have been caught if AC had been stricter or if validation evidence had been demanded?"
    • Applied by: whoever finds the defect (AM, CEO, contractor, client-reported via AM).
  • quality:partial-met — Task closed with one or more AC bullets only partially met, by mutual agreement. The unmet portion is documented in the close-out comment and either deferred to a follow-up task or accepted as a known limitation.

External-dependency state​

  • blocked-on:client — paused awaiting client response, decision, or asset.
  • blocked-on:vendor — paused awaiting a third-party vendor (a WP dev partner, an IT/DNS vendor, Stripe support, registrar, etc.).
  • blocked-on:hosting-support — paused awaiting hosting provider on a support ticket.

Add new blocked-on:* tags via PR if a recurring external dependency emerges (blocked-on:legal, blocked-on:bank, etc.).

What is NOT a tag​

  • Status — use ClickUp status (to do, in progress, blocked, complete, cancelled). Statuses are defined in SC Task Data Standard §1.
  • Priority — use ClickUp priority field.
  • Assignee — use ClickUp assignee field.
  • Due date — use ClickUp due-date field.
  • Effort estimate — use ClickUp time-estimate field.
  • One-off context — write it into the task description, not a tag.

If a piece of metadata fits a structured ClickUp field, use the field. Tags are for telemetry-grade categorical metadata that doesn't fit a structured field.

Tag removal procedure​

A tag is removed from the taxonomy when it no longer maps to a recurring need — replaced by another tag, made redundant by a structured field, or attached to a workflow that has been retired.

Triggers for removal:

  • Usage falls to zero in the last two quarterly audits AND no upcoming work is expected to use it.
  • A new tag supersedes it (the new tag's PR should call out the supersession).
  • A workflow that produced the tag is retired (e.g., a deprecated SOP).

Who approves: the Workspace Owner. Surfaced via PR amending this doc — never apply a removal in ClickUp before the PR lands.

The PR pattern:

  1. Open a PR that:
    • Removes the tag's row from §Approved tags.
    • Adds a one-line entry under §Removed tags (see below) recording: tag name, removal date, reason, supersession (if applicable).
    • Notes whether existing tasks carrying the tag will be (a) migrated to the supersession tag, (b) left as-is to die with the task lifecycle, or (c) bulk-cleared.
  2. On merge, the Workspace Owner (or designee) performs the ClickUp-side actions in order:
    • Existing tasks first. Carry out the disposition decided in the PR — migrate / leave / clear. If migrating, use ClickUp bulk-edit. If leaving, document the rationale on the recurring audit task.
    • Then remove the tag from the space-level picker. ClickUp space settings → Tags → delete. Once removed from the space picker, no new task can apply the tag (closes the source).
  3. Post a comment on the recurring audit task naming the removed tag + the disposition action + the PR URL — audit-comment requirement matches the Quarterly audit procedure format.

What happens to historical tasks carrying the removed tag:

  • If the tag was removed from the space picker but left on tasks (disposition (b)): the tasks still display the orphan tag for historical readability. Cross-task views filtering on the tag still work for those tasks. New tasks cannot apply the tag.
  • If migrated to a supersession (disposition (a)): the new tag carries the same semantic; reports that group by the new tag will pick up history.
  • If bulk-cleared (disposition (c)): use only when the tag carried no semantic value worth preserving. Generally avoid — historical telemetry is the main reason the tag existed.

Anti-patterns:

  • Removing a tag from ClickUp without amending this doc (creates an orphan; the doc keeps claiming the tag is approved).
  • Amending the doc without doing the ClickUp-side cleanup (the picker still offers the tag → it gets re-applied).
  • Bulk-clearing the tag from historical tasks without recording the rationale (loses telemetry).

Removed tags​

(Empty as of 2026-06-14 — no tags have been removed since the taxonomy was established.)

TagRemoved dateReasonSupersession (if any)Disposition for historical tasks

Quarterly audit procedure​

Run once per quarter. Allocate ~30 minutes.

  1. List all space-level tags. In ClickUp, navigate to space settings → Tags. Copy the full list (name + usage count if available).
  2. Diff against §Approved tags. For each tag in ClickUp not in this doc → orphan. For each tag in this doc not in ClickUp → missing (create it at space level so future tasks can apply it).
  3. Resolve orphans. For each orphan:
    • If it represents a recurring need not yet captured → open a PR amending this doc, then keep the tag.
    • Otherwise → remove from ClickUp. If the tag is on existing tasks, decide per case: replace with the canonical equivalent, or accept the tag dies with the task list.
  4. Resolve missing. Create any missing canonical tags at space level so they appear in the picker.
  5. Log the audit. Post a one-paragraph summary as a comment on the recurring audit task: tags added, removed, renamed; any open follow-ups.