# Client onboarding intake worksheet

Use this worksheet to define an intake app in Overskill. The filled example is a fictional website project. Replace its requirements with the decisions your team actually needs before kickoff.

## 1. Name the project and roles

- Project and client workspace:
- Client who supplies the material:
- Assigned reviewer:
- The work that may start once this intake is accepted:
- Anything still needed outside the intake, such as an agreed scope or scheduling:

Keep credentials out of intake answers. Record the person responsible for access and the approved invitation method; never collect their password or token here.

## 2. Choose the active requirements

The example always requires Project contact and Project goals. Add the relevant rows below.

| Condition | Answer | Add |
| --- | --- | --- |
| Existing brand assets? | Yes | Logo reference; color references |
| Existing brand assets? | No | Brand direction brief |
| Replacing an existing website? | Yes | Page inventory; delegated-access confirmation |
| Replacing an existing website? | No | Proposed sitemap |

An unanswered question keeps the full requirement set incomplete. It does not mean No.

| Existing brand | Existing website | Required total |
| --- | --- | ---: |
| No | No | 4 |
| No | Yes | 5 |
| Yes | No | 5 |
| Yes | Yes | 6 |

Your conditions and additional requirements:

| Condition | Answer | Required item | Who supplies it? | Who accepts it? |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |

## 3. Review a particular revision

| State | Meaning | Next action |
| --- | --- | --- |
| Missing | No revision has been submitted | Client supplies the item |
| Submitted | Current revision awaits review | Assigned staff review it |
| Needs changes | Reviewer returned the current revision with a reason | Client submits a new revision |
| Accepted | Reviewer accepted the current revision | Preserve that decision; a replacement needs another review |

For each item, keep a stable item ID, revision number, submitter, submission time, reviewer, decision and decision time. Acceptance names the revision reviewed. If that revision changed after the reviewer opened it, reject the old review action and show the new material. Do not carry an old acceptance onto a replacement. The simulator uses numbered events to keep the fictional sequence readable; a real app also needs its recorded times.

| Required item | Current revision | State | Review reason / next action |
| --- | --- | --- | --- |
|  |  |  |  |
|  |  |  |  |

## 4. Check the filled case

Both project conditions are Yes. Contact, goals, colors, page inventory and delegated-access confirmation are accepted. Logo revision 1 is submitted.

| Step | What changes? | Accepted / required | Ready? |
| --- | --- | ---: | --- |
| A | Five accepted; logo revision 1 submitted | 5 / 6 | No |
| B | Reviewer requests full-color and single-color logo references | 5 / 6 | No |
| C | Client submits logo revision 2 | 5 / 6 | No |
| D | Reviewer accepts logo revision 2 | 6 / 6 | Yes, for this example's intake |
| E | Client replaces it with logo revision 3 | 5 / 6 | No; revision 3 needs review |
| F | Existing brand changes to No | 4 / 5 | No; brand direction is missing |
| G | Existing brand changes back to Yes | 5 / 6 | No; retained logo revision 3 still needs review |

In step F, logo and colors are inactive. Their prior values remain visible in the example but are excluded from the active checklist. The readiness answer concerns only this declared intake; it does not authorize a contract, confirm scheduling or finish the project.

## 5. Carry this into your build

Use the [Overskill brief builder](https://www.overskill.com/learn#brief-builder). Include your active requirement rules, the four states, the worked checks and these permissions:

> Clients can read and submit inputs only in their own project. Assigned staff can review only authorized projects. Clients cannot accept their own submissions. Enforce permissions on the server for records, files, search, exports and changes. A new revision needs a new review. Preserve prior revision decisions. Explain what is saved and verify it after leaving and returning.

Ask for a first version with one fictional client project and no notification sends. Test a second client's copied links and the staff review actions before using real material. Use Start build as the primary handoff once your brief is ready; keep a copy for comparison.

## 6. Record your observed result

| Test | Expected | Observed | Pass / fail / not tested |
| --- | --- | --- | --- |
| Unanswered condition | Incomplete, no stale ready result |  |  |
| All required items submitted | Awaiting review, not ready |  |  |
| Current revisions accepted | Ready under declared intake rules |  |  |
| Replace accepted item | New revision awaiting review |  |  |
| Switch conditional branch | Only active items counted/exported |  |  |
| Client tries staff decision | Server rejects it |  |  |
| Another client opens item/file/export | Server rejects it |  |  |
| Save, leave and return | Same authorized project's current state |  |  |

The public example stores nothing and reload clears it. Passing its local rules does not establish persistence, file checks or permissions in a generated app.