Use this checklist at the right stage.
This guide is for a business preparing the inputs for an agreed customer-process setup. It is not a first-inquiry form, a purchase agreement or permission to begin work. The actual service instructions and written scope determine when setup can proceed.
If you are still considering options, the Local Growth Call preparation guide is the better starting point. A fit conversation does not require you to assemble a complete implementation package or grant account access.
Once a path is agreed, describe it in one sentence: where the request arrives, which decision comes next and who handles it. List what should remain unchanged. That boundary helps the people preparing the setup distinguish a necessary input from an interesting idea for later.
Ask what each input will help someone decide.
Start with information already supplied. Check whether it is current before asking the business to enter it again. For every additional item, name the decision or task it supports. If nobody can explain its purpose, clarify the request before collecting it.
On a small screen, swipe or scroll sideways to read the full table.
| Input | What it helps establish | What not to assume |
|---|---|---|
| Included entry points | Where the selected requests originate. | Every channel is included or connected. |
| Owners and exceptions | Who reviews a request and who decides an unusual case. | A named employee has accepted every task. |
| Operating coverage | When the agreed team can handle the selected step. | Public opening hours equal staffed response hours. |
| Current wording and source | Which customer instructions can be used. | An old brochure still describes the approved process. |
| Existing tools to retain | Which records or routines must remain usable. | A new setup authorizes replacement or migration. |
| Known restrictions | Which actions need review or must not occur. | A demonstration has approved real customer contact. |
A fictional request is often enough to explain the handoff. Do not send an entire customer database when a process description and an anonymized example can answer the question.
Separate the approver from the operating owner.
The approver can confirm decisions within their authority. The operating owner understands how the team will perform the work. One person may hold both roles, but they are different responsibilities.
An owner might approve which requests the business accepts, while an office coordinator confirms who reads them and when. Ask both perspectives to review assumptions that affect their work. A polished diagram is not enough if the person expected to handle the next step has never seen it.
Record who supplies an input, who checks it and who can accept the resulting decision. Where a backup is needed, confirm that arrangement rather than adding a name speculatively. Unresolved ownership remains an open item in the preparation record.
Make the status of each input mean something.
A file arriving is progress, but it may contain outdated or incomplete information. Use statuses that tell the next person whether the item is ready to rely on.
On a small screen, swipe or scroll sideways to read the full table.
| Status | Meaning |
|---|---|
| Not needed | The responsible reviewer confirmed this item is unnecessary for the selected scope. |
| Pending | An identified input or decision is missing; someone owns the next step. |
| Received | The item arrived in the agreed location. Its accuracy or sufficiency has not yet been established. |
| Reviewed | Someone checked it and recorded either a finding or an unresolved question. |
| Accepted for this setup | The authorized reviewer confirmed the information is suitable for its stated purpose and scope. |
Record who made the decision and the source they used. “Accepted” here applies to an input. It does not mean the installation passed its checks, the service launched or live access was released.
Limit a missing item to the step it actually affects.
Fictional example: A repair business is preparing a website estimate-request path. Nadia, the business owner, has approved the request types. Lee, the office coordinator, has accepted responsibility for reviewing them. Their submitted coverage note says only “Monday–Friday.” It does not give review hours, a time zone or the plan for requests arriving outside coverage.
The note is received and reviewed, with a question still open. It is not sufficient to finalize when a request can receive an office review or what the related customer wording should say. Public business hours should not silently fill that gap.
Lee checks actual staffing; Nadia confirms the intended coverage and exceptions. The preparation owner records that dependency against the affected review step. Previously accepted request types and ownership remain recorded. Other preparation may continue where the responsible person confirms it does not depend on the missing hours.
Do not declare the whole project blocked or promise a launch date from this example. Record the limited impact, its owner and the next agreed check. Reassess affected timing after the missing decision is accepted.
Hand over a small, reviewable package.
Download the blank setup-input checklist (CSV). Use a row for each necessary input or decision. Keep the completed copy in your approved workspace and use references to supporting material instead of duplicating private records.
Account access needs separate, verified instructions explaining the specific purpose, recipient, permissions and review or removal plan. Do not put passwords, security codes or recovery information in this checklist. If the available screen differs from the instructions, ask the responsible person rather than sharing a login.
Before the handoff, check that unresolved items have owners and that accepted inputs still match the agreed path. New requirements belong in a separate change decision. Once the agreed setup is complete, the prelaunch review checks actual behavior. Preparing the inputs alone does not prove that behavior works.