Practical guide

Intake checklist or delivery task: keep the boundary clear

Last materially reviewed 2026-09-19

Quick answerA completed onboarding checklist means you are ready to work—not that the purchased work is complete.
What to know

Separate readiness from production

An intake checklist gathers the information and access needed to begin. A delivery task records the work itself. Mixing the two can make a dashboard look busy while nobody knows whether production has started. For a website banner, receiving the logo is an intake event; creating and approving the banner is delivery. A clear boundary helps the client understand why a submitted request may still be waiting for a missing dependency.

What to know

Create a ready-to-start decision

Use a short check of brief, assets, entitlement, owner and approver. These are our proposed operating fields, not a required ManyRequests schema. The responsible person confirms readiness before committing production capacity. If a dependency is missing, keep the request visible with that reason. Avoid silently assigning it a deadline based on the original submission time when the team could not yet perform the work.

What to know

Prevent checklist duplication

If the same brand asset applies to several jobs, keep one authoritative reference rather than requesting a fresh upload each time. Conversely, a reused asset does not make a new brief complete. Distinguish organization-level information from job-specific instructions. Check the actual portal’s supported handling before automating this distinction. The goal is to avoid burdening the client with repeated setup while preserving the details that make each deliverable different.

What to know

Show the next action clearly

A useful status reads waiting for approved copy, owner client contact, production not started. It is more informative than onboarding incomplete. When the missing item arrives, record the readiness decision and move the original request forward. Do not create a second ticket that loses the intake history. A good portal implementation reduces questions by making this transition explicit, rather than promising that any checklist with all its boxes ticked represents completed client work.

Continue when useful

Next: ManyRequests vs Content Snare: requests or missing inputs?

Use a collection tool for a collection bottleneck; evaluate a delivery portal when the work continues after the brief arrives.

Open ManyRequests vs Content Snare: requests or missing inputs? →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. ManyRequests getting started — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
  2. ManyRequests managing requests and exporting data — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19