Make the invisible workflow visible.
The timesheet project is not blocked by coding effort. It is blocked by turning Kim's day-to-day judgement into a clear rulebook, then connecting that rulebook to Launch27, Toby's sheet, Slack, and the dashboard.
Kim's daily time across approval clicking and post-Toby edits.
Approximate daily bookings Kim reviews in Launch27.
Approximate manual edits after Toby's adjustment process.
Kim verifies exceptions and mismatches rather than doing every click.
Past State: Human Effort Carries The Workflow
Launch27 stores the raw entries, but Kim supplies the interpretation. Toby supplies adjustment logic separately through the sheet.
Field staff use Launch27
Check-in/out, travel, distance, and timing are entered inconsistently.
Kim reviews one-by-one
She checks duration, Slack, missing logs, staff type, job type, and manual duration.
Kim exports CSV
She formats the sheet and prepares daily tabs for Toby.
Toby adjusts sheet
His script populates adjustment columns, then the tab becomes ready for Kim.
Kim edits Launch27 again
She applies adjustments record-by-record, then mentally verifies completion.
Future State: Automation Does The Routine Work
The future flow keeps Kim as rule owner and exception reviewer. The system handles repeatable reads, writes, handoffs, and verification.
Pull from Launch27
System reads pending time logs and supporting booking fields where available.
Apply Kim's rulebook
Clean cases are approved; uncertain cases become dashboard exceptions.
Prepare Toby sheet
Daily export is formatted and Toby is notified when ready.
Apply Toby edits
Once done, the system writes approved adjustments through Mark's proxy.
Verify and surface mismatches
Kim sees only exceptions, mismatches, and anything the system refuses to guess.
Before / After By Process
There are three distinct processes. The first saves the most time and must be understood first.
Past: Kim as the processing engine
Kim clicks and edits hundreds of rows using SOP plus experience.
Kim exports, moves columns, formats tabs, and sends to Toby.
Kim reads adjustment rows and manually updates Launch27.
Mostly manual confidence and spot checks inside the same fragile workflow.
Future: Kim as rule owner and reviewer
Automation approves only cases covered by Kim's rulebook.
System prepares the sheet consistently and notifies Toby.
System applies known edits through the proxy after Toby is done.
Dashboard shows matches, mismatches, audit history, and exceptions.
Data Flow: Where Information Moves
The core identity problem is simple but critical: Launch27 writes use (booking_id, team_id). Toby's sheet must preserve or recover that identity.
Raw time logs, statuses, check-in/out, enroute times, distance, booking details, manual duration.
Supabase + dashboards.maid2match.com.au hold the local workflow, audit log, exceptions, and verification results.
The Three Processes
Keep these separate. They are related, but each has a different source of uncertainty.
Daily Approval
Biggest time saver. Blocked by Kim's rulebook: below schedule, special staff, job types, whole-day decisions, Slack proof, manual duration.
CSV Export + Toby Handoff
Smaller time saver but needed for the full workflow. Blocked by final sheet layout and notification preferences.
Post-Toby Edits + Verification
High value, but blocked by column meanings, sheet row identity, Toby done trigger, proxy read/verification behavior.
Who Does What
A swimlane view helps separate operational rules from technical plumbing and sign-off.
Decision Board
This is the short list that explains why the project feels stuck. The next meeting should unlock the left column.
(booking_id, team_id).active:false do?Rulebook Areas Kim Needs To Make Explicit
This is the meeting heart. We need to turn "Kim knows what to do" into written rules.
| Area | What Kim decides today | What the system needs | Why it matters |
|---|---|---|---|
| Duration | Within 10%, over schedule, under schedule. | Precise thresholds and actions. | Core approval logic. |
| Proof | Slack extension, support update, manual duration. | Where to search and what counts as valid proof. | Prevents bad auto-approvals. |
| People | Contractors, TLs, flat-rate staff, exceptions. | How to identify staff category. | Some logs should be skipped, not approved. |
| Job types | Inductions, one-on-ones, travel, late cancel, bond clean. | How to identify each type and cap values. | Rules depend on context, not just time. |
| Grouping | Whole-day and multi-staff checks. | When rows must be considered together. | Prevents row-by-row automation from doing the wrong thing. |
Tomorrow's Kim/Kiara Session
Keep it practical. Ask Kim to teach the current process, not to imagine automation.
Best framing for Kim
"We are documenting how you already decide what to approve, edit, skip, or follow up. Short examples are enough. If it depends, tell us what it depends on."
What not to ask
Do not ask Kim how the automation should be designed. Ask what she sees, checks, decides, edits, and escalates today.
Approval rules
Walk through normal, over, under, missing, and special cases. Capture examples.
Evidence and data
Where she checks Slack, manual duration, booking status, staff role, job type, and whole-day context.
Toby handoff inputs
Clarify what Kim knows about the sheet, then take unresolved sheet questions to Toby.
Milestone View
The project becomes easier once each milestone has one concrete output.
Output: explicit approval rulebook and examples.
Output: final sheet columns, row identity, and done trigger.
Output: read capability, active flag meaning, partial failure behavior.
Output: final pre-build handoff document with no hidden judgement calls.
Output: scaffold and first shadow-mode workflow, once rules are known.
One-Sentence Mental Model
The simplest way to explain the whole thing.
We are replacing Kim's repeated Launch27 clicking with a system that applies her documented rules, refuses uncertain cases, hands clean data to Toby, writes approved edits back through the proxy, and gives Kim a dashboard for the few things that still need human judgement.