Deliver and close a scoped customer project

Organise production and delivery as separate tasks, record the receiving decision and complete the project only when its scope is accepted.

Before you start: Have the agreed deliverable, current version, acceptance criteria, delivery method and responsible people. Decide what the recipient must be able to read or use before calling the work delivered.

Steps

1. Open Board → Projects on the intended Board and search for the project. If it already exists, skip step 2 and review its tasks. Reuse matching production or delivery tasks below rather than creating duplicates.

2. Select New Project. Check Board and Project Name, enter a Description with the purpose, included output and exclusions, and set the intended dates and initial Planned status. Select Create Project, then open the saved project and check its scope.

3. For missing work, use the top + (Create New) → New Task to create a production task and a delivery/acceptance task. Give each a clear title and put its completion condition in Description. Select the intended Board and actual assignee.

4. Under Relationships → Project, select the exact project on each task. Set task dates separately where needed, then use Create Task for a new task or Update Task for an intended edit. Reopen each task and expand the project’s chevron to check both relationships.

5. Produce the complete agreed output and review it against the acceptance criteria. Keep the version identifiable. If you need a stored file, upload it once in Files, then use Related Documents → Attach from Vault on the task or project to select that existing item; save each association through its own update action.

6. Deliver the complete version through the agreed method. For an inline Inbox delivery, use Compose, check From/To, include the full output and version, and select Send once. Inspect the full Sent message before retrying an uncertain result. For a stored-file delivery, confirm the intended recipient can actually read that file, not just see its filename.

7. Ask the authorised recipient to check the received version against the agreed requirements. In the delivery task’s Comments → Write a comment, record the actual acceptance or specific changes needed and the version it concerns. Submit only a new decision and reopen the saved comment.

8. When each task’s own completion condition is met, set its Status & Planning → Done and select Update Task. If a task is already correctly Done, leave it unchanged. Missing receipt or acceptance means the delivery task is still unfinished.

9. Open the project, check the linked tasks and accepted scope, then set Project Status → Completed and select Update Project when the whole scope is complete. Skip this transition if already correct. Return to Projects and reopen the project and tasks to compare their retained states.

Expected result

The project links the production and delivery work, the accepted output version is identifiable, and task and project completion match the actual result.

Common pitfalls

• Project dates do not automatically populate task deadlines, and completed tasks do not automatically establish the project’s own state.
• A stored file, attachment chip or sharing entry is not proof of readable delivery. Check the intended recipient’s access to the agreed version.
• Do not bypass an organisation’s blocked file viewer or widen sharing to force delivery. Resolve the permitted route with the owner.

Continue learning

In this series: Customer enquiry to delivery — guide 3 of 3.

• Previous: Hand an agreed customer scope to delivery
• Optional related guide: Run a customer job from enquiry to cash
• Browse tutorials