Your Vendor QBR Shouldn't Be Their Show

The deck arrives the morning of the QBR.

Fill rate: 87%. Time to submit: 3.1 days. "We're proud of the partnership and look forward to continued growth in Q3."

You have a spreadsheet you pulled two nights before. Fifteen columns, some formulas that broke, and numbers you're not entirely sure match theirs.

The meeting runs 50 minutes. The vendor walks through their wins, explains away the gaps, and floats a premium tier with faster turnaround. You say you'll consider it. They leave.

You came to hold a vendor accountable. You ended up sitting through their quarterly highlight reel.

Why your data doesn't help as much as it should

Most mature programs have VMS data. Fill rates, submission timelines, end-of-engagement ratings, maybe cost-per-engagement. The data is not the problem.

The problem is what it takes to turn that data into something you can actually use in a room. You need to pull it, clean it, segment by vendor and role category and time period. You need to compare across vendors using consistent definitions. You need to check whether a vendor's submit time looks good because they're fast, or because they're flooding you with warm bodies to hit the metric.

That work takes two to four hours if you're experienced and the export behaves. If you're covering six to ten vendors across multiple markets, you either do a shallow pass or you skip it. Most QBR prep ends up being whoever pulls a report 24 hours before the call.

So the vendor walks in prepared. You walk in reactive. And they set the frame.

This is not a data access problem. It's a data processing problem. The signal is there. Nobody has time to hear it.

One Solution: Using Gumloop to automate Vendor Scorecard

What does the Gumloop Automation do?

The setup is a Gumloop workflow that runs monthly. The inputs are two things: a) a VMS export, and a short configuration document that lists your vendors, your role categories, the metrics that matter to your program, and b) any known context (a specific vendor is new, one market had unusual demand that quarter, a role category was reclassified mid-period).

Gumloop takes those inputs, passes them to Claude, and returns a formatted scorecard. Every vendor ranked across the same set of dimensions. Fill rate, yes. But also submission quality measured by interview-to-offer ratios where available, cost performance against your internal benchmarks, extension rates, and early termination flags. Each vendor gets a one-paragraph summary and a gap analysis that names where they underperformed and by how much.

The workflow runs without you initiating a manual analysis. By the time you're sitting down to prepare for a QBR, the scorecard is already there. You're not building the picture. You're deciding what to do with it.

In the QBR, you come in with specific questions. "Your submit time improved but your interview conversion dropped 14 points. Walk me through what changed." You're steering the conversation instead of receiving it. The vendor stops presenting and starts answering.

Building the workflow

If you want to build this workflow for your program, or want help structuring the configuration document and scorecard logic, reach out directly. I work with a small number of programs on exactly this.

You do not need to be technical to set this up. Gumloop is visual. The workflow has four nodes.

The first node is a file trigger. This is where the VMS export lands. Most VMS platforms let you export a standard CSV covering the period you want: open engagements, submissions, fill outcomes, bill rates, end-of-engagement ratings, extensions, and early terminations. If your VMS does not have a clean export, a manually compiled spreadsheet works. The cleaner the data, the sharper the scorecard.

The second node is a text input. This is your configuration document. It does not need to be long. Two pages covers it. List your active vendors by name. List your role categories. Specify which metrics matter most for your program and what good looks like for each one. Note anything the AI needs to interpret the data accurately: a vendor that only came on in month two, a market that had unusual churn, a role category that was reclassified mid-period.

The third node is a Claude AI node. You paste your prompt here. This is the one below, adapted to your program. The fourth node is a text output or document formatter, which takes Claude's response and saves it somewhere you can access monthly: a shared folder, a Notion page, an email to yourself.

The whole workflow runs in under four minutes once it is built. Building it the first time takes about two hours, most of which is cleaning your first export.

The prompt you paste into the Claude node is direct. This version is written for Claude but works without modification on GPT-4o, Gemini, or any LLM with a sufficient context window:

"I am preparing for vendor QBRs for my contingent workforce program. I have attached a VMS export covering [time period] and a configuration document that explains the program context and scoring priorities. For each vendor in the data: calculate fill rate broken down by role category, interview-to-offer conversion rate, average bill rate versus the benchmark I have provided, extension rate as a percentage of total engagements, and any early termination flags. Rank each vendor from highest to lowest performer across each dimension. Write a one-paragraph performance summary per vendor that names their strongest and weakest dimension. Flag the top two issues per vendor that I should raise in the QBR. Output a ranked scorecard table first, then the vendor summaries."

The output is structured. Something like this:

Vendor A. Rank: 1 of 5. Fill rate: 91% overall, 88% technical, 94% operational. Interview conversion: 62%. Bill rate: on benchmark. Extension rate: 14%. No early termination flags. Consistent performer with a fill rate that holds across categories. Interview conversion is the gap. Worth asking whether candidate quality or brief quality is the driver.

Vendor B. Rank: 4 of 5. Fill rate: 79% overall, 61% technical, 88% operational. Interview conversion: 44%. Bill rate: 8% above benchmark across four engagements in Q2. Extension rate: 31%. One early termination flag in March. Underperforming on technical roles and pricing. The extension rate suggests scope is not being defined clearly at engagement start. The bill rate creep across Q2 needs a direct conversation.

What it surfaces

Fill rate masking. A vendor hitting 85% fill rate looks adequate. Break it down by role category and they're at 94% on administrative roles and 61% on technical specialist roles. The aggregate number hid the actual performance problem.

Rate creep across engagements. No individual engagement looks unusual. But over six months, the same vendor has moved their average bill rate up 11% through a combination of role reclassifications, contract amendments, and new engagement types.

Metric gaming. Vendors with consistently strong submit times but three times the submission volume of others. Fast submit time, achieved by sending everyone they had. The metric looked healthy. The behaviour wasn't.

Tenure-cost drift. Engagements that extended past the original term without formal review were costing on average 18% more by month four than comparable fixed-term engagements.

What it can't do

The scorecard shows you what happened. It does not tell you why. A vendor underperforming in Singapore in Q2 might reflect a talent supply problem, a poor job brief, a specific relationship issue, or a pricing mismatch. Claude cannot know which. The scorecard tells you where to look and what questions to ask. The QBR conversation still requires judgment.

The workflow also depends entirely on data quality. If your VMS has inconsistent role categorisation, missing engagement ratings, or vendors logging activity differently across regions, the output will reflect that. Garbage in, confident output out is the failure mode. The first three months are calibration, not conclusion.

Where this is heading

The more useful version is continuous. Several VMS platforms are building API access that would allow a workflow like this to run on a rolling basis rather than monthly. That changes the QBR from a quarterly surprise to a review of a conversation that has been running all quarter. Some larger programs are already testing this architecture. It is not ready out of the box for most. But it is closer than it was 18 months ago.