Plans and ProgressFour workflow model · updated 16 October 2026
Command CenterMain pageClient accessPlansTools

Workflow material

Open the workflow visual

The visual map for onboarding, support, jobs, and invoicing.

Open →Detailed proposal

The full step-by-step reference: owners, ClickUp states, current status, decisions, and open questions.

Open →Page guide

What every button, field, card, and status on the client portal, team portal, and Tech Hub is supposed to do.

Open →
One source for the operating model

Four workflow plans

Manual onboarding, support, job requests, and invoicing. Each case has one ClickUp task linked to the portal client record; the portal remains the customer record and ClickUp is where the team handles the work.

Status key
  • Green — live and verified
  • Gold — built but off, or needs proof
  • Red — missing or blocks the workflow
  • Cost rule — no alert, automation, or AI use is turned on without explicit approval of its cost or quota effect.

The workflows

1Manual client onboarding

For clients who do not begin through website checkout. Portal access comes first; workspace access follows payment.

Ops + Tech
MissingStart the client recordKimi agrees service; create Onboard task → New.
DraftSet up portal and paymentOps creates the onboarding record; Billing sends the approved $50/month payment link → Awaiting payment.
Needs proofMatch paymentStripe or GHL records payment by client ID and invoice ID → Paid.
LiveBuild and protect workspaceTech provisions, attaches monitoring, backup, and key escrow → Building.
MissingRelease workspace accessOps supplies the n8n link only after payment → Live.
Needs proofClient connects toolsClient uses portal Connect; first backup closes onboarding → Done.

2Support and incidents

A client request and a monitor-detected incident enter one system without an alert flood.

Jason + Ops
LiveClient opens Get HelpPortal creates the request → New.
Built, offMonitor creates one incidentUptime, backup, or portal failure → one task, repeat alerts increase its count.
Needs setupAssign and triageOps sees every case; Jason / Tech owns incidents → Triaged.
LiveWork and log notesTeam Tickets page carries the history → In progress.
DraftShow client statusPortal mirrors a plain status line; Tech closes → Resolved.
MissingReview overdue workOne-business-day tech due date and daily overdue view.

3Job requests

The $50 plan covers the workspace. Quoted implementation work is separate and paid before building starts.

Ops + Billing
LiveClient submits request“Ask the implementation team” → Submitted.
MissingScope the workTech reviews tools, setup, and requirements → Scoping.
Needs updateQuote in the portalOps writes; Kimi approves price → Quoted. Old hours model must be removed.
Needs proofClient decisionClient approves or declines → Approved / Declined.
MissingRaise job invoiceBilling creates an invoice only after approval; payment is upfront.
Team workBuild and deliverTech works → Delivered; client confirms → Completed.

4Invoicing

Monthly workspace subscriptions and separately quoted job work. Billing changes belong to Codex’s lane.

Billing + Codex
LiveWebsite $50 paymentStripe checkout needs no team task.
ManualManual payment linkBilling task → Sent after approved wording.
LiveMonthly renewalStripe subscription; real scheduled renewal still needs observation.
MissingJob invoice on approvalCreate a draft for Billing to review and send; never auto-send.
Needs proofMatch payment and show receiptUse client ID + invoice ID; display receipt on Billing page.
Manual closeCancellationMark automatically; Tech closes workspace at end of paid month.

Jason’s monitoring handoff

This is a red operating item, not a request to change any account yet.

  • Direct monitoring access: the exact dashboard and permissions Jason needs.
  • Incident definition: which workspace, backup, portal, and website failures become one ticket.
  • Escalation route: what Jason handles, what goes to Tech, and how Kimi is informed.
  • First alert proof: one safe, verified notification reaches the right work record without Resend or email.
  • Daily ownership: Jason confirms open incidents and overdue cases are being worked.
Approved operating rules
  • ClickUp is the team work record. Portal status links to it; email is not the work channel.
  • Ops sees every case. Tech works infrastructure incidents.
  • Tech tickets are due in one business day. Weekend handling needs confirmation.
  • Overnight AI prep proposes only. It changes no client workspace, and its per-ticket cost needs approval before activation.
  • Job work is paid upfront. The invoice route, Stripe or GoHighLevel, remains open.

Open choices before automation

ClickUp location

ClickUp is where this work lives; no new tool or space. Own the Stack list: open in ClickUp. Kimi prefers one task per case with subtasks for the steps, kept in as few places as possible. Kimi, 10/16: one list beside it, OTS Service Desk, holds the casework, split by type: Tickets (anything flagged, by a client, the team, or a monitor; errors are tickets), Job requests (a client wants something built), Invoices (manual invoices sent out), and Onboarding (manual clients).

Weekend tickets

Confirm that Friday evening and weekend work is due by end of Monday.

Uptime Kuma into tickets

Team notices are decided: Agency OS notifications plus the ClickUp assignment. Still open: how monitoring incidents reach that record. It cannot use Resend or email.

Notion's role

A copy of the ClickUp board for Kimi to view, or kept out of tickets.

Job invoice route

Choose Stripe or GoHighLevel for the approved-job invoice draft.