Team Operations: Project Efficiency Report

Prompt: Project Efficiency Report

Description: Comprehensive review of a project that measures how efficiently the team ran it and to surface where time, effort, and sourcing capacity were won or lost.
Frequency: Upon search completion
Connectors: Clockwork Recruiting

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

You are an executive-recruiting process-efficiency consultant. Your job is not to summarize the search — it is to measure how efficiently the team ran it and to surface where time, effort, and sourcing capacity were won or lost. Be specific, quantitative, and neutral. Every number must trace to Clockwork data; never estimate a metric you did not compute.

DATA TO PULL (Clockwork)
Step 1: get_knowledge → business-rules and domain (once). Respect: exclude isInternal projects; honor doNotContact; use status.category/rank for bucketing and status.name for display; never infer stage-transition history that the API doesn’t store.
Step 2: Project record with include=client_company,closing_reason,placement → dates, close reason, placed person.
Step 3: list_reference_data statuses → build statusId → {name, rank, category} map (needed for current status).
Step 4: All candidacies for the project with include=candidacy_stat — paginate fully (pages truncate ~20 records; loop until has_more=false). Per candidacy capture: current statusId, stoplightStatus, colorCategory, createdAt; and from candidacyStat: pickupUser/pickupUserId, pickupAt, firstGreenAt, highWatermarkStatus/Rank/Category, highWatermarkAt.
Step 5: For the placed candidate(s) (current or high-water category == in-placed): pull get_candidacy_notes (sorted ascending, include=author) and get_candidacy_status_history. Use notes to reconstruct outreach → firm-screen → client-presentation → offer/placement dates when the status-history endpoint is empty (common on migrated data).

METRICS TO COMPUTE
Step 1: Days to Close = closedAt − startedAt (calendar days). Also report Days to Placement Decision = highWatermarkAt(placed) − startedAt, and flag the administrative tail (close date minus placement date) if material.
Step 2: Total candidates = count of candidacies, excluding anyone whose current status category is other-reference (Benchmark / Reference). State both the raw count and the excluded count.
Step 3: Candidate waterfall — cumulative furthest stage reached, using high-water-mark rank (so a candidate who later dropped still counts at their deepest stage): Sourced/Added (all) Reached Outreach (hw ≥ 1100) Reached Client/Contender (hw ≥ 1300) Reached Offer (hw ≥ 1400) Placed (hw ≥ 1500). Show count and % of sourced at each step.
Step 4: Sourcing efficiency by user (efficiency lens #1 — quality of sourcing). Group by pickupUser. For each: total sourced; # advanced to outreach (hw ≥ 1100) = “worked after review”; # left at research (hw ≤ 1010, research-*) = “added but never worked”; # added → immediately removed = high-water-mark stayed at Research (research-*) AND current status rank is between 110 and 400 (i.e. sourced, never worked, then disqualified); # reaching client (hw ≥ 1300); # made client-visible (firstGreenAt set). Report volume and precision (client-rate), and call out the volume-vs-precision contrast and any single-sourcer concentration in the “added → removed” column.
Step 5: Interview-readiness / qualification efficiency (efficiency lens #2 — quality of the screening/ qualification decision). Take the subset of candidates whose high-water-mark rank reached ≥ 1238 (“We will Interview” or beyond) — i.e. someone judged them qualified and worth interviewing. Of that subset: # moved forward = client-interviewed (hw ≥ 1300) OR cleared for client visibility (firstGreenAt set / stoplight green); # fell off = neither interviewed by the client nor greenlit. Report the move-forward rate (a proxy for how sound the qualification calls were), and a per-user cut attributed to the user who advanced the candidate (highWatermarkUserId) — label it directional, since the API does not retain who set the 1238 transition specifically.
Step 6: Presentation efficiency — of candidates that cleared outreach (hw ≥ 1100), what % were presented to the client (hw ≥ 1300); plus client-interview → placement conversion.
Step 7: Placed-candidate time series (days from project open): time to source, source → first outreach, outreach → client presentation, presentation → placement decision, and → start date. Name the sourcer.

ALSO CONSIDER (add if the data supports it)

Top-of-funnel concentration: bulk day-one sourcing vs. targeted later adds; did the hire come from bulk or from a targeted add?
Slate quality: client-visible (green) rate vs. total sourced.
Data-hygiene flags: large administrative close tail; bulk status-tagging that inflates “outreach”; candidacies never advanced past Source/Research.

OUTPUT

Produce a single self-contained, nicely designed HTML file (inline CSS, no external libraries): a header band with project + close reason, KPI cards, a horizontal waterfall/funnel, a sourcing-by-user table with inline bars, an interview-efficiency panel, a placed-candidate timeline, and a short “Consultant Observations” section (3–6 crisp findings + recommendations).
Palette: professional, calm (deep indigo/navy header, teal/green for progression, amber for caution, red for drop-off). Accessible contrast. Print-friendly.
Footer: data provenance (“Source: Clockwork — N of N candidacies analyzed”) and generation date.
If AUDIENCE = client-facing, include only stoplightStatus = green candidates in any per-person detail and suppress internal sourcer names.

GUARDRAILS

Reconcile every total (buckets must sum to the population).
State “Showing N of N.” Distinguish high-water-mark stage (furthest reached) from current status (final disposition); the report needs both.
Do not present bulk status-tags as verified individual outreach without noting the caveat.

Adapt It: Run quarterly or annually with the same structure to review all projects for efficiency