The problem being explored
Feeling busy and being productive are not the same thing. The gap is usually invisible.
The specific pattern this build is modelled on: a small sales team where the calendar is perpetually full but the pipeline is not growing as expected. Everyone is in meetings. Everyone is handling follow-up. Everyone feels like they do not have enough time. But nobody has a clear view of whether the time is going to the right work.
The problem is structural. Calendars are designed to schedule time. They are not designed to diagnose how time is actually being spent. A calendar full of meetings looks exactly the same as a calendar full of the right meetings. The tool that tracks the time has no opinion about whether the time is well-spent.
What the diagnostic surfaces
Three signals from calendar data
Meeting load: what proportion of the week is scheduled time vs. available time? Is the ratio sustainable for the role? Does it leave room for execution work between commitments?
Manual overhead: which recurring events represent work that repeats every week without producing anything new, status updates, admin reviews, report prep? These are the automation candidates.
Protected focus time: are there contiguous blocks of time long enough to do focused work? A schedule with six one-hour meetings spread through the day may have the same total available hours as one with a clear morning block, but the deep work capacity is very different.
Where the design took a side
Three choices that shaped what the diagnostic became.
Decision 1
Categorise the calendar, not just count the events
A raw count of meetings per week is not diagnostic. It does not distinguish between a two-hour strategy session that moves a project forward and a two-hour status update that could have been a message. The build uses Claude to categorise calendar events by type, pipeline, admin, internal sync, client, focus time, so the diagnostic can say how much time went to each category, not just how many events occurred.
This categorisation step is where the most judgment is required and where the most error occurs. Calendar event names are inconsistent. "Weekly sync" could be anything. The concept uses a first-pass categorisation and surfaces the events for human review, the assumption is that the person reviewing the diagnostic knows which events belong in which categories, and the tool gives them a structured view to work from.
Decision 2
Show the implication, not just the data
Raw categorisation data is useful context. What drives the action is the implication. "You spent 14 hours in meetings this week" is a data point. "14 hours in meetings left 6 hours of available execution time, distributed across 12 blocks with an average length of 30 minutes" is an insight about why deep work felt impossible this week.
The build tries to surface the implication of the data rather than just presenting the data. This is the hardest design problem in diagnostic tooling: the gap between "here is what happened" and "here is what it means" requires interpretation that is context-dependent.
Decision 3
One week, not one quarter
The build is deliberately scoped to a single week of calendar data. This is a concept limitation that would not survive in production. You need at least a month of data to identify patterns versus one-off weeks, but it makes the concept more legible. One week of data is fast to process, easy to inspect, and sufficient to demonstrate the diagnostic model.
A production version would track rolling weeks and identify patterns over time: is meeting load increasing quarter over quarter? Is focus time being protected or eroding? The week-level view is the foundation; the trend is what makes it operationally useful.
What is deliberately over-built
The categorisation layer.
The concept uses AI categorisation for every event, which produces a rich diagnostic at the cost of some accuracy. A production version would likely combine AI categorisation with explicit user tagging for recurring events, "this is always admin, stop asking", to improve reliability over time.
The visual model is also more detailed than a daily production tool would need. A production version would probably lead with a simple score or summary, "this week was 70% meeting-heavy, down from 65% last week", and make the full breakdown available on demand rather than presenting it as the default view.
The operational implication
It shows what the week costs in focus time. It does not decide what to cut. That is yours.
Categorising time and computing execution capacity needs a tool. Whether a specific recurring meeting is worth its cost does not, that depends on what the meeting decides and the relationships it holds, so it stays with the person who knows the work.
This build is that method in practice: a clickable diagnostic that changes the brief.
How to test a workflow with a live artifact ->If your team is busy but not productive in the ways that matter, the workflow diagnostic is a useful starting point.
The concept shows the model. A practical implementation starts with the specific question you are trying to answer about how time is being spent, and builds the categorisation schema around the work categories that matter for your role.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
