1. Create the working location
Start with one List, not a second sales pipeline.
01
Create a Sales-to-delivery List
In the Spaces sidebar, hover over an internal Space accessible to both teams, click the plus icon and select List. Name it Sales-to-delivery and click Create. A separate Folder is optional. Do not change an established shared Space just to try this example.
02
Create one task for the deal handoff
Name it Cedar Demo / D-204 / onboarding handoff. The deal reference distinguishes another engagement from a duplicate transfer. Search for D-204 before creating it.
03
Name the preparer and reviewer
Sales prepares the brief. A delivery reviewer accepts it or returns a specific gap. In this example the task assignee owns the next action, so that assignment changes when the task is returned.
04
Use the due date for the next internal action
Choose a review deadline matching working coverage. Record the customer kickoff separately in the brief; one date should not mean both a review deadline and a customer promise.
2. Configure List statuses
Separate a review request from acceptance.
Open the List menu and its status settings. Set List-specific statuses rather than editing inherited Space statuses. Use these names as the example team’s agreement.
| Status / group | Meaning | Next-action owner |
|---|---|---|
| Preparing / Active | Sales is assembling the handoff. | Sales owner |
| Ready for review / Active | Sales requests a check of the current brief and scope. | Delivery reviewer |
| Needs information / Active | A comment names the gap preventing acceptance. | Sales owner |
| Accepted / Done | The receiver accepts the handoff and records the next delivery step. | Receiving owner, with delivery work tracked separately |
3. Add working fields
Use fields for filtering and the description for context.
Create Custom Fields on this List. In a task’s Fields area, use the add-field control and select the List location. Keep the longer brief in the description. These are proposed field choices, not a mandatory ClickUp template.
| Information | Field | Example use |
|---|---|---|
| Deal reference | Text Custom Field | D-204; check for another task with the same reference |
| CRM record | Website Custom Field | Link to the approved deal record; no automatic sync |
| Sales owner | People Custom Field | Who can correct the brief |
| Receiving reviewer | People Custom Field | Who is asked to accept it |
| Return reason | Dropdown Custom Field | Missing scope / Missing dependency / Owner unclear / Other |
| Next-action owner | Built-in assignee | Reviewer when ready; Sales when returned |
| Next-action deadline | Built-in due date | Current internal review or repair deadline |
Customer: Cedar Demo
Deal reference: D-204
Goal: Replace the weekly manual onboarding tracker.
Agreed scope: One intake form and one internal progress view.
Scope reference: Link to the approved CRM record or document.
Not included: Historical data migration.
People: Sales owner, delivery reviewer, customer project contact.
Dependency: Customer must name who can approve access.
First milestone: Agree intake fields at the kickoff.
Kickoff: To be agreed; no date promised in this example.
Open question: Who approves access?
Acceptance: Reviewer, date and the scope reference reviewed.
Delivery work: Link to the delivery task or project after acceptance.These are field prompts, not completed acceptance evidence. Replace the role placeholders with named people and record acceptance only after the reviewer checks the scope.
4. Save working views
Make the waiting work easy to find.
Create List views on the handoff List. Show status, assignee, due date, deal reference, reviewer and return reason as useful columns. Use each view’s Filter control, then save its settings. Test these proposed combinations with the fictional task. Keep an unfiltered List view available as well: a date-filtered queue is not a completeness check for tasks without a due date. Create the initial task in that unfiltered view, then check its status and dates. ClickUp documents that tasks created inside filtered views can inherit filter values; creating one in the review queue can therefore put it into review before the brief is ready.
| View | Filter logic | What happens here |
|---|---|---|
| Review queue | Status is Ready for review | Reviewer accepts or returns the brief. |
| Returned to Sales | Status is Needs information | Sales repairs the named gap before resubmitting. |
| Due or overdue handoffs | Status is any of Preparing, Ready for review or Needs information, AND due date is today or earlier | Inspect next owner and reason. Today is due, not already overdue. |
5. Walk Cedar Demo through it
Return one missing dependency in the same task.
01
Sales submits D-204
Sales enters the agreed scope, names the reviewer, assigns them the next action and sets the review deadline. The task moves from Preparing to Ready for review.
02
Delivery returns the access question
The reviewer comments: Name the customer’s access approver before we accept. Set Return reason to Missing dependency, status to Needs information and next-action assignee to Sales.
03
Sales repairs and resubmits
Add the approver, keep the earlier discussion, clear the return reason and assign the next action back to the receiving reviewer. Agree the next-action deadline and set Ready for review again; do not hide the earlier request by creating another handoff.
04
Delivery records acceptance
The reviewer records the scope reference checked, their acceptance and the first next step. Link the actual delivery work and set Accepted. A later material scope change requires another review under the team’s rules.
6. Optional automation
Add one review prompt after the manual flow works.
The handoff works without this Automation. If your plan and role permit it, add a comment when a task enters Ready for review. The comment prompts a decision; it does not accept the handoff.
01
Open Automations on the handoff List
Click the robot icon, choose Create Automation and start a custom Automation. Keep it at List scope so unrelated delivery tasks are not included.
02
Select the status-change trigger
Set the destination status to Ready for review. Scope it to tasks, not subtasks, for this example. Do not add an action that returns the task to the same triggering status.
03
Add a review comment
Choose Add a comment. Use: Check the scope, dependency and next owner; accept or return this handoff with a reason. Name the Automation clearly and create it.
04
Try returning and resubmitting
Inspect the comment and Automation Activity after D-204 enters review. Resubmission may add another prompt in this design; it must not create another handoff task or accept the work.
Before using real customers
Try the cases that can make the board misleading.
These are proposed checks, not results of a live ClickUp test. Use fictional tasks and the permissions of the people who will actually do the work.
| Try | Evidence to look for |
|---|---|
| A task is created from a filtered review view | Check inherited status and dates; it must not appear accepted or ready merely because the creation view supplied values. |
| A handoff has no assignee or internal due date | Find it in the unfiltered List and assign the missing next action before relying on filtered queues. |
| Ready for review with a dependency missing | The reviewer returns a specific gap; status alone does not claim completeness. |
| A returned handoff is resubmitted | Same reference and discussion remain; assignment and deadline are checked. |
| Reviewer cannot open the scope link | Access problem stays visible; nobody accepts unseen commitments. |
| Automation is unavailable or fails | The queue works manually; Activity is checked for an enabled rule. |
| Another task is created for D-204 | An owner reconciles both before delivery. This setup does not enforce uniqueness automatically. |
| Accepted task has a future kickoff | Handoff leaves active-review views; delivery work and deadlines stay visible elsewhere. |
