Team Operations: Team Capacity & Workload Comparison

Prompt: Team Capacity & Workload Comparison

Description: Shows how project and candidacy load is distributed across the team over a window, highlighting who is overloaded, who has headroom, and how it has trended.
Frequency: Weekly or on demand for resourcing decisions
Connectors: Clockwork Recruiting

Prompt: (copy/paste the prompt below into your chat in your LLM)

Build a Team Capacity & Workload Comparison for the period [default: last 30 days; ask if I want a different window].

Step 1 — Fetch the roster via list_reference_data(data_type=users), keep Partner/Recruiter/Researcher/Admin, cache the map.

Step 2 — For each member, pull their book directly with get_user_projects(user_id=..., status=active, include=lead,owner,client_company). For each, compute:

Active projects assigned (display as <Company> \ <Project>)
Total active candidacies (filter rank >= 100; if a project has multiple team members, divide by team size for fair allocation)
Active candidacies in client-facing stages (status.rank >= 1300; confirm the threshold if the firm's progression differs)
Notes authored in the window (engagement proxy)
Distinct people personally interacted with in the window
New projects added to their plate in the window

Step 3 — Compute a normalized capacity index per user: (weighted_candidacies × 1.0) + (client_facing_candidacies × 1.5) + (new_projects × 5) and express each user's load as a % of the team average and team max.

Step 4 — Trend: compare to the prior equivalent window and show direction (↑ ↓ →) per user.

Output: (1) a markdown table sorted by capacity index descending, with raw counts, index, % of average, and trend; (2) a horizontal █-bar visualization to eyeball the spread; (3) a Resourcing Recommendations section — who is over capacity (>130% of average), who has headroom (<70%), and which specific active projects (by <Company> \ <Project>) could be reassigned or supported.

Adapt It: Change the window or weighting to match how your firm thinks about load Scope to one pod for a resourcing huddle Add fee-weighting so revenue-heavy searches count more Run it before assigning a new search to see who has room