← All work Case study · Client operations

Northstar Client Hub

One screen for an agency's client services team: money, goals, monthly health checks, tasks and incoming checks, pulled together from the tools they already use.

My role

Concept, workflow design, system architecture and build direction

Built with

Claude, Bonsai, Google Sheets, Gmail

Used by

Three account leads, plus bookkeeping and leadership views

Status

In use by the client services team

Try the live demo

The real hub belongs to the agency I work for. The demo and screenshots here are a rebuild with a fictional agency, clients and numbers. Same logic, new brand.

Live demo

Try it right here.

Switch who you're viewing as, log a check that doesn't match, or open the Demo panel to run the automations. Everything is fictional, and your changes stay in your browser.

Open full screen

markneyens.com/northstar

Northstar Overview: client list with billing, goals and retainer dates

Open the live demo

The problem

Everything lived in a different place.

The owner didn't have one place to see every client. Neither did the rest of us.

The team worked across a handful of tools: Bonsai for invoices and projects, a Google Sheet called the Burnsheet for revenue, proposals for retainer terms, and email and memory for everything else. Simple questions meant jumping between all of them. Is this client healthy? What's overdue, and is a check already on the way? Which retainers end soon? It was scattered, and it was frustrating.

I wanted one place that answered those questions for the owner and the team, without asking anyone to give up the tools that already worked.

What I built

One page, six tabs, five kinds of users.

OverviewA card for every client: retainer end date, goals on track, billed this year and anything overdue. Tap one for terms, goals, contacts and live projects.
Client HealthA monthly check. Retainer clients are rated Good, Watch or At risk across 8 areas. Any At risk flags the whole client; otherwise the majority wins. Everyone else gets a quick Active, On hold or Inactive.
TasksEvery to-do from every health check in one list, soonest due first, overdue in red. Each can become a Bonsai task or an email.
BillingThe invoicing meeting on one screen: what's sent, what's still to go out, what's overdue by lead, renewals coming up and checks not yet recorded.
ScorecardWeekly numbers for each lead against goal: yearly revenue under management, billable hours, quarter growth and loss, and which Burnsheet lines moved.
ChecksLog a client check the day it arrives, before Bonsai shows it paid. It clears on its own once the invoice is marked paid.

How it works

It reads from our tools. It doesn't change them.

The hub reads from the systems the team already trusts and keeps its own notes in its own database. It never edits the Burnsheet. The only thing it ever writes to Bonsai is a task someone creates on purpose.

Sources

BonsaiInvoices, projects, team. Live, refreshed every 15 minutes.
Read only

The BurnsheetGoogle Sheet with each client's revenue. Synced weekday mornings.
Read only

Accepted proposalsRetainer terms, entered by hand. Bonsai's connection can't see proposals.

Client HubBuilt as a Claude artifact with its own database

Overview
Client Health
Tasks
Billing
Scorecard
Checks

Team inputRatings, notes, goals, contacts, to-dos and checks, saved in the hub's own database.

Outputs

GmailMismatch alerts and reminders to the account lead. To-do emails only when someone clicks Email.

Bonsai tasksCreated only when someone asks. The single write to Bonsai.

Scheduled tasksThree automations keep revenue, scorecards and reminders current.

Decisions that mattered

The choices that made it work.

Read, don't write

Finance owns the Burnsheet and Bonsai is the system of record. The hub only reads them, so nobody had to trust a new tool with the books.

Roles that match real jobs

Leads can edit everything. A bookkeeper on the check-only list opens straight to a phone-friendly Log a check screen. Leadership sees Overview and Billing only. Check photos stay with people who log checks.

Catch mistakes at entry

A check that doesn't match its invoices is flagged and the lead gets an email. A possible duplicate within 7 days gets a warning. Whoever logged a check can fix or undo it the same day.

Show the system's limits

Bonsai's connection can't see partial payments, so a partly paid invoice looks fully open. Instead of hiding that, a Data check panel lists it for editors, along with unmatched Burnsheet lines and missing renewals.

Keep the monthly habit easy

"Start from last month" copies last month's ratings and notes, so a lead only changes what moved. Reminders go out on the 1st and 10th.

Phone first where it counts

The flows people use most, logging a check and reviewing a client, work as compact cards on a phone.

Automations

It keeps itself current.

RUM SyncWeekdays, 6:54 amCopies each client's revenue under management from the Burnsheet into the hub.
Scorecard UpdateWeekdays, 7:14 amRebuilds each lead's scorecard and records which Burnsheet lines changed since last week.
Health Check Reminder1st and 10th, 8:49 amEmails the account lead a list of clients whose monthly check isn't finished.

Billing tab with overdue invoices grouped by lead and upcoming renewals — Billing runs the monthly invoicing meeting from one screen.

Log a check form flagging that a $3,500 check doesn't match a $3,521.37 invoice — A check that doesn't match its invoices gets flagged before it's saved.

Phone view of the check-only screen with a simple Log a check form — The bookkeeper's whole hub: one form.

How I built it

I designed it. Claude helped me build it.

I owned the problem, the workflow and the rules: what each role should see, which systems the hub may touch, how a rating rolls up, when a check counts as recorded. Claude was my build partner for the code, inside a Claude artifact with scheduled tasks for the automations.

It went through many versions. I put early builds in front of the people who would use them, watched where they got stuck, and folded their feedback into the next round. Every change is written up in a how-it-works doc with a change log, so the team can trust it and someone else could maintain it.

See it for yourself

Switch roles, log a check, run the automations.

Try the live demo More work