A single source of truth for Partner Basecamp programme data
This site publishes the survey findings from every Partner Basecamp cohort — updated after each event and shared with BTS colleagues delivering the programme. It is a single source of truth: a consistent, versioned record that anyone with a BTS login can access and compare across cohorts.
Reports are generated directly from participant survey responses using a pipeline of Python scripts. Everything on the site comes from that data with no manual editing. When a new cohort runs, the reports are regenerated and the site is updated within hours.
Four types of report — each serving a different purpose
Audience & reach
Cross-cohort view of who attended, where, NPS over time, org reach, and capability profile. Descriptive — no interpretive commentary. Run after every cohort.
NPS, outcomes & patterns
Interpretive analysis: NPS by persona and proficiency, confidence before vs after, open-text synthesis, and systematic patterns across the programme.
Per-event analysis
Detailed breakdown for one cohort: audience, NPS, D1 ratings, D2 confidence, open text. Generated by analyze.py for each event.
Per-firm survey record
NPS history, participation, persona mix, and benchmark comparisons per partner firm, alongside a feedback log and open action items. Generated for firms meeting the participation threshold.
Key metrics explained
The metrics here serve different analytical purposes and build on each other. Descriptive metrics — NPS, attendance, org reach — tell us what happened and who was there. Diagnostic metrics — persona breakdowns, confidence deltas, proficiency segments — help explain why the programme landed the way it did for different groups. The pipeline scripts produce both. Turning those into insights — interpreting what the patterns mean, what's driving them, and what to do about them — is where the analyst takes over from the script.
| Metric | What it measures & how to read it |
|---|---|
| NPS | Day 2 recommendation score, −100 to +100. Weighted aggregate across cohorts accounts for different cohort sizes. An open-text follow-up question is asked of all respondents regardless of score — participants say what's behind their rating. This is the primary diagnostic layer for NPS: the scores tell us where we stand; the open text tells us why. |
| Confidence delta | Change in self-rated confidence from Day 1 (before the programme) to Day 2 (after). Positive delta = participants left more confident than they arrived. Reported per competency area and as an overall mean. |
| Depth / Pace / Relevance | Three Day 1 ratings (1–5 scale) on programme design: was the content deep enough, was the pace right, was it relevant to their role? Shown as mean scores with distribution bars. These feed back to facilitation decisions for future cohorts. |
| Personas |
These are Anthropic's definitions of the partner ecosystem roles the programme
is designed to serve. Participants self-select from four function groups in
the Day 1 survey; those map to three personas used throughout the reports. NPS and
outcomes differ meaningfully across all three — the splits are more useful than
the programme average alone.
Developer (Engineering) — Engineers and developers who build, integrate, and deploy AI solutions. They work at the implementation layer: writing code, integrating APIs, and putting AI capabilities into production. Architect (Architecture) — Technical architects responsible for AI strategy, system design, and the frameworks that guide how AI is adopted across an organisation or client engagement. They operate at the intersection of technical depth and strategic direction. Transformation Lead (Business Leadership · Project/Engagement Management) — Commercial and delivery leads who connect AI work to client outcomes. They operate across business development, engagement management, and strategic leadership — the people who decide whether AI initiatives get resourced, scoped, and delivered. |
| AI proficiency | Self-reported on Day 1: Learning and exploring, Applying in practice, Delivering independently, or Operating at the frontier. Used to segment NPS and confidence data — Frontier participants typically start with higher confidence but show smaller deltas; those still learning and exploring show the largest shifts. |
| D1 / D2 respondents | D1 = Day 1 Pulse survey respondents (programme design feedback). D2 = Day 2 End of Session survey respondents (NPS, confidence). D2 is typically smaller as some participants leave before the closing session. NPS and confidence figures come from D2. |
How data gets from survey to report
It helps to distinguish three levels of output the pipeline produces. Data is what analyze.py extracts — numbers, counts, distributions. NPS is data. Findings are patterns that emerge when data is read across cohorts and segments — "NPS varies significantly by persona" is a finding, surfaced by insights.py. Insights are interpretive claims that explain findings and point toward action — "the Architect NPS gap reflects a content calibration issue, not audience quality" is an insight, and it requires analyst judgment to reach. The pipeline handles the first two; the third requires a human in the loop.
docs/
folder and pushed. The site updates within about one minute. Raw survey data
never enters the git repo or this site.
Planned additions to the pipeline and site
These are deferred until the underlying infrastructure is ready. The current pipeline — Box for data, git for scripts, Cloudflare Pages for hosting — is the stable foundation they'll build on.
Questions, gaps, or things that look wrong?
This site is only useful if the data it shows is trustworthy and the reports answer the right questions. If you notice something that looks off, want to see a metric that isn't here, or have a question about how something is calculated, reach out to Ted.