Client onboarding & project setup

Content requests arrived at very different levels of detail: sometimes a title or keyword, sometimes an attached brief, sometimes instructions spread across a conversation. The onboarding system gave operations a repeatable place to capture the client context before passing work to writers. Its purpose was to make each new assignment understandable without requiring the writer to reconstruct the sales conversation. Noah documented the setup and coordinated changes with teammates; the request-form walkthrough explicitly credits a cofounder with helping build it.

The client record held information reused across assignments: company name, website, brand description, English variant, contact and routing information, production instructions, folder reference and Harvest client ID. Earlier Notion records also linked the point of contact, draft writer, final writer and complexity context. An article request carried its own title, target length, due date, keywords, notes and attachments. These were related records rather than a new independent copy of the whole client relationship for every article.

There were two distinct template layers. A Google Docs template controlled the shape and appearance of the writing document, including fonts and recurring sections. A ClickUp task template carried client instructions, content-type subtasks and default assignees. New articles and article refreshes could use different templates because their work and delivery steps differed. A client working across separate websites could require separate content-type or destination templates. This is a documented design, not a claim that every client had a completely populated profile.

In the request-form version, operations first used an internal form to choose which fields a client should see and, for an existing client, provide the ClickUp client-record ID. The system created a branded redirect and posted it in Slack. Initially that link opened signup, collecting company and contact details. After signup the same link redirected to the recurring content-request form. Hidden parameters carried client identity and form settings between the stages. Clients did not have to enter their brand background each time.

Form configuration followed the information the client could actually provide. A client already supplying detailed documents could receive a short title-and-upload form rather than a compulsory long questionnaire. The walkthrough describes a default due date four days after submission when none was supplied; this was a historical configuration, not a current turnaround commitment. The client ID selected update-versus-create behavior. Supplying it for an existing client was therefore an important operator check. The link was stored in the client record so staff could recover it when needed.

The later content-request walkthrough also describes a different inheritance route: each incoming request copies the current client-record fields, so staff can change those fields without resaving the ClickUp template for that form path. This should be distinguished from the manual task-template path, where reusable edits must be saved to the template. Neither description establishes live synchronization of previously created articles.

The dedicated new-client scenario deliberately started when a record was created in the ClickUp client list. This allowed records originating in Typeform, the application or manual entry to use the same provisioning path. A standard template was applied and a webhook called Make. A thirty-second delay allowed an operator to correct the client name before asset creation; Make then retrieved the updated record rather than assuming the initial webhook had the final values.

The scenario checked for an existing client folder, created a client folder and a Projects subfolder when needed, and copied the default writing template into the client root. Client-wide style material stayed above individual article folders so writers could distinguish reusable guidance from project-specific attachments. It created the Harvest client and wrote the Harvest client ID and client-folder reference back to ClickUp. Saving the enriched record as a task template carried those identifiers into later orders. The folder field supplied the location explicitly; names alone did not associate the task with its client folder.

Operators still needed to check the entered information, choose the right template and save recurring changes to that template. Adding a one-off note to an article did not automatically change the instructions for all later work. The older Notion template-enhancement brief asked a teammate to replace a single universal document template with per-client copies. Later ClickUp explanations show this client-specific lookup in use, using the template term in the document name. The progression supports an evolving system rather than a claim that the first enhancement brief was already finished.

Migration required care. Standardized subtasks did not automatically retain all old checklists and submission details. Noah instructed operations to inspect retained older records before creating replacements. Template access also changed from admins to members after people could not use them. Existing backup tasks supported manual recovery; the sources do not establish complete automatic migration.

The request-form demonstrations show a generated link, signup creating or updating a client, and a request reaching the queue with client information and an attachment. They also show English-variant mapping, empty-field rendering and missing-subtask defects. File upload needed adjustment during the later walkthrough. Platform-specific welcome text and allowing clients to configure their own fields were proposed extensions. The useful outcome to describe is a demonstrated intake and provisioning structure with visible defects and human checks, without claiming measured turnaround gains or a universally finished rollout.