INVIZ.tv / Client operations / System 01 of 04
2023Recorded work
Client-facing boards and onboarding progress
Give each client an onboarding checklist and reflect its progress in the team’s central view, one way only.
- Noah’s contribution
- Specified the board/register model, demonstrated board creation and status updates, and tested the guest-facing view.
- Historical stage
- Historical scoping, configured board-creation/status tests and guest-view check; later internal-board redesign remained a change brief.
- Part of the business
- INVIZ.tv overview ↗
- Monday.com
- Make
- Board templates
- Webhooks
Inside this system
The workflow
The handoffs
inside the work.
Follow the main path and its branches. Select a step for context; the account below explains what was built, tested or planned.
- Client-board template test
Create the client-facing checklist from a template; the test used a static company name. - Client-facing onboarding board
Expose the onboarding tasks and statuses for the invited client. - Central client register
Retain the associated board ID and the onboarding summary for each client. - Guest-account access check
Inspect the invited board and task interactions from a separate account. - Client task-status event
A changed task on the external board supplies the progress update. - Find client by board ID
Use the stored association to locate the matching register record. - Update central progress
Reflect the matching status fields and progress in the client register, one way only.
Key records
The information
that carries forward.
| Record | Information | Purpose |
|---|---|---|
| Client register | Client identity, associated board ID, onboarding status fields and progress. | Show the team where each client stands without opening every board. |
| Client-facing board | Onboarding tasks and their status, shared with the relevant guest. | Give the client an actionable view of the onboarding work. |
| Dashboard status mapping | Short labels used to associate an updated task with the relevant status field. | Keep the visible progress labels concise while retaining a mapping to source tasks. |
Inside the system / 01
One client view and one operating view
INVIZ needed clients to see and complete onboarding tasks while the team retained a central picture of all client relationships. A board per client supplied the detailed checklist; the client register supplied the summary. The early brief also considered how a board ID on the register could connect events from a specific board with the correct client.
The configured demonstration used two workflows. One created the client board from a template and added a record to the client register. The other reflected task updates from the client board onto that record. The test started with a static company name. Document signing through PandaDoc or DocuSign was discussed as a future source for the trigger and client information.
Inside the system / 02
Keep synchronization intentional
The demonstrated status sync ran from the client-facing board to the central register. It was explicitly one-way, avoiding the circular-update risk of treating every change on either side as a new instruction. The register included onboarding progress alongside the individual task statuses.
A subsequent change brief altered the desired relationship: the external board would connect to an internal launch board, with only the client-onboarding task group synchronized. Other internal tasks would stay outside that sync. Noah also described shortening dashboard labels and mapping updates through a dedicated dashboard-status value. This later redesign is distinct from the earlier demonstrated register-based version.
The early recommendation to centralize onboarding information also explained why this association mattered beyond the first checklist. Keeping a client’s internal board, external board and form information together would give later workflows a consistent lookup point. That was an architectural recommendation; the narrated board-creation and status-change tests establish the narrower working component.
Inside the system / 03
Test access and define the rollout boundary
Noah invited a separate email as a guest and inspected the resulting view. The guest could see the invited board and interact with its tasks. That check is specific evidence of the tested sharing arrangement; it does not establish automatic guest provisioning or a separate custom web portal.
Before updating existing launch boards in bulk, Noah asked which launches and external copies should change, and whether repeat launches required another onboarding section. Those questions were still open in the recording. A separate proposal for a stable onboarding-to-dashboard link and Slack-assisted manual invitation also remained a design option, rather than a demonstrated automatic invitation service.
Within INVIZ.tv