Chapter 10 of 13 · Toolkit, any time · About 15 minutes

Compare your results with outside data: live queries and public datasets

Your own numbers tell you what happened in your program. A board or funder often asks the next question: compared with what? The answer sits in other systems, like your CRM, and in public datasets from the Bureau of Labor Statistics, the Department of Labor and the IRS.

On this page: Two ways · What MCP is · Match definitions first · The wage example · Keep names out · Sources · Limits · Try it · Questions

What are the two ways to bring outside data into your reporting?

In short: query it live, where it already sits, or load it once as a fixed reference. Live suits everyday questions whose answer changes every week. Loading once suits benchmarks and compliance checks that everyone must read from the same file.

What is MCP, in plain terms?

In short: MCP, the Model Context Protocol, is a shared way for an AI assistant to ask questions of another system's data. The data stays in that system; the assistant reads back the answer.

Each system that supports MCP offers a connector, and you approve which ones your assistant may use. Anthropic published MCP as an open standard in 2024, and Claude and ChatGPT both use it. HubSpot offers a connector, and Claude or ChatGPT can query Sopact Sense data the same way.

The weak point is the join. The assistant must match an employer in HubSpot to the same employer in your placement records, so agree one spelling, or better, one employer ID in both systems.

Why must definitions match before you compare?

In short: a comparison is only fair when both numbers count the same thing, for the same people, place and period. Write both definitions in one row first.

Outside sources define things their own way. A wage estimate may cover every worker in a job, not new hires; a public placement rate may use a different window after exit. It is the same discipline as checking a partner's report against the agreement: when Partner C counted placements within six months instead of 90 days, the fund held its number back. Treat an outside figure the same way.

How do you compare starting wages with the local wage for the same job?

In short: match each training track to an occupation code, pick the wage estimate for the same area and year, and compare hourly with hourly. Compare new graduates with the lower end of the local range, not only the median.

The fictional workforce fund's agreement asks for starting wage, hourly, by track. Each track trains for a job with a Standard Occupational Classification (SOC) code; a medical assistant track, for example, maps to SOC 31-9092. The Bureau of Labor Statistics publishes hourly wages for that code by state and metropolitan area.

New hires usually start below the median for everyone in the job, so show the 25th percentile beside the median.

Partner C's single average wage cannot enter this comparison: it mixes tracks. That is why "Can you split starting wage by track?" was one of the fund's three questions.

How do you keep names out when you connect outside data?

In short: compare on groups and codes, never on people. A wage benchmark needs a track and an area, not a name, so choose the fields an AI tool may see before you ask anything.

Public data describes occupations, employers and organizations, so it needs no person's name. Your records hold names and emails; send counts, tracks, wages and dates instead. A live query sends the AI tool whatever it returns, so the same rule applies.

In Sopact Sense today, field selection lets you choose which fields are sent to AI and keep names and emails out. The AI Assistant stays locked until you declare which surveys it may use. Public data you load as an ordinary survey follows the same rules as your own. More on this in what the assistant may see.

Which public sources are worth using, and what should you watch for?

In short: for workforce programs and grant makers, three federal sources cover most needs: wages, employer enforcement records and charity filings. Each is reliable for what it measures and misleading when stretched past it.

Confirm a charity's current status with the IRS's own Tax Exempt Organization Search. Record the download date and reference year of every loaded file, so the comparison can be traced to its source.

I will give you two tables. Table 1: our starting wages, hourly, by training track, for people placed in a job within [PLACEMENT WINDOW] of exit, with the count of people per track. No names. Table 2: BLS Occupational Employment and Wage Statistics for [AREA], reference year [YEAR], with the SOC code, 25th percentile and median hourly wage.

1. Match each track to one SOC code. If a track fits no code or several, say so and skip it.
2. For each matched track, show our wage, the BLS 25th percentile and median, and the difference per hour.
3. List every difference in definition (who is counted, area, period, new hires vs all workers).
4. Do not estimate any missing value. Mark it "missing".
5. Write two plain sentences for a board, naming the area and the BLS year.

What can outside data not tell you?

In short: it gives context, not proof. Public data lags, uses its own geographies, and shows how two numbers relate, not why.

Wage estimates describe a year that has passed; your graduates started work this year. Metropolitan areas rarely match your service area. If graduates earn above the local 25th percentile, report it, but it does not show the training caused it: the people who enroll may differ from the typical local worker. Keep the comparison beside your own results, never in place of them.