Before a client project starts, your team needs the right material and a clear answer about what has been accepted. A form can be fully submitted while a logo, page list or project goal still needs work.
Use this optional Part 2 recipe to plan a client intake app in Overskill. You will leave with conditional requirements, review rules and a short example your first build should pass. The client portal guide covers the wider workspace; this exercise focuses on the handoff into a project.
The fictional website studio needs six items when a client has existing brand assets and is replacing an existing site. In the example, five items are accepted and the logo is waiting for review.
Load the example, switch to Reviewer and request changes to the logo. Switch to Client to submit a new revision, then review that revision. The result becomes ready only after the current revision is accepted. Submit another revision and watch readiness change back.
Fictional website project
Try the intake and review loop
Choose what the project needs, then switch between the client and reviewer views. Every item below is sample information; nothing is uploaded or sent.
Choose both project conditions
The manual rule table below works without JavaScript.
Inactive items retained in this example
These values remain in this tab so you can switch back. They do not count toward readiness and are excluded from the active checklist.
Your active checklist
Choose both conditions to prepare a checklist.
Use the rule table without the simulator
Start with Project contact and Project goals. Add one row from each condition below. A required item counts only when its current revision is accepted. Missing, submitted and needs changes all remain unfinished.
| Condition | Answer | Additional requirements |
|---|---|---|
| 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 |
Example: existing brand plus existing site needs 6 items. Five accepted and one submitted means 5 of 6 accepted and Not ready. Accepting that last revision gives 6 of 6. Replacing it with a new revision returns the result to 5 of 6.
The example clears when you reload or leave. It checks intake readiness only; it does not verify files, grant account access, start work or save a project.
The role switch lets you explore both sides of the example. A real app needs separate accounts and server permissions. This tool uploads nothing, sends nothing and clears when you leave or reload.
Ask only for the material this project needs
Start with two questions: does the client have brand assets, and are you replacing an existing website? Project contact and project goals are required in every branch.
| Project answer | Additional material |
|---|---|
| Existing brand: Yes | Logo reference and color references |
| Existing brand: No | Brand direction brief |
| Existing website: Yes | Page inventory and delegated-access confirmation |
| Existing website: No | Proposed sitemap |
That produces four required items for a new brand and new site, five when only one condition is Yes, and six when both are Yes. An unanswered condition leaves the requirements incomplete.
If an answer changes, recalculate the active list. The example keeps inactive values visible in the current tab so you can switch back, but excludes them from readiness and the active checklist download. Decide what your own app should retain and explain that choice to clients.
For access, record the person who will invite your team and the approved invitation method. Keep passwords and tokens out of the intake. A submitted note about access is not proof that an invitation was sent or that access works.
Accept the revision you actually reviewed
Give each required item four understandable states:
| State | What happens next |
|---|---|
| Missing | The client supplies the item |
| Submitted | Assigned staff review the current revision |
| Needs changes | The client sees a reason and submits a new revision |
| Accepted | Keep the decision attached to the reviewed revision |
The logo example makes the distinction visible. Revision 1 can be returned for missing references. Revision 2 can be accepted. If the client then supplies revision 3, the previous decisions remain history and revision 3 awaits review. The new file must not inherit the old approval.
Keep the item ID, revision, submitter, reviewer, decision and recorded times together. A review action should name the revision shown to the reviewer; if that version changed, ask them to read the new one before deciding. “Needs changes” should explain what the client must supply. The example uses ordered events to show that history; the app you build should also record when each action occurred.
Make the readiness answer useful
For this example, readiness means both project questions have answers and every active required item's current revision is accepted. Five accepted plus one submitted is 5 of 6, with one review still needed. Six submitted is 0 of 6 accepted.
This is an intake rule you can adapt. It does not establish an agreed contract, a booked start date or completed project work. Show those decisions separately if your workflow needs them.
Download the editable intake worksheet to write your own requirements and review rules. Download the worked example data for the initial 5-of-6 case. The tool's active checklist gives you the current answer for the branch you selected, with visible JSON you can copy if downloading is unavailable.
Build the intake loop in Overskill
The Agency Onboarding Funnel catalog page describes a guided intake for company details, goals and brand assets. Use it as a candidate to inspect, then verify its questions, storage and access behavior against your own workflow. The fictional review rules above are requirements for your build; they are not a claim about that template's implementation.
In Part 3, bring your requirement matrix and example into the Overskill brief builder, or inspect the linked remix entry. Ask for one client project, conditional required items, revision history and a staff review view. Include your specific access rule: clients may submit only to their own project, and only assigned staff may accept an item. Review and edit the brief, then choose Start build.
In Part 4, test one complete loop: submit, request a change, replace, accept, leave and return. Repeat a copied record, file and export link with another client account, and try a staff-only decision as the client. The private access checks and interruption worksheet help you record the observed result before inviting real clients.