← The Operations Station ~ dish 07 of 10 · the operations station

Vendor and Partner Triage

The Chef's habit problem isn't the station can't read vendor pitches. It's we never wrote down what tier each vendor request belongs in or what criteria move a pitch from "archive" to "warm." Without those rules, the station can sort but can't decide.

The job

Requests land every week. A vendor wants to pitch an integration. A partner wants to explore a deal. A consultant wants to set up a call. The Chef’s inbox fills. Some are worth the time. Most aren’t. Someone needs to read the inbound, decide which are real, and route them. Right now that’s the Chef or an admin. By week two, the station does it.

The dish reads the inbound request. It identifies the type (new vendor pitch, existing vendor upsell, integration proposal, partnership exploration, consultant cold call). It scores the relevance (how aligned with current roadmap). It flags if the request matches a known vendor or a prior conversation. It routes to the right person or archives it with a summary. The Chef’s inbox stays signal-rich.

Plated well, this looks like: the right opportunities surface. The Chef sees warm deals but not the fifty cold pitches. Existing vendor conversations are tracked (no one loses context on a prior relationship). Edge cases (a vendor you’ve been considering) are flagged for human review. The triage happens automatically. The Chef approves exceptions.

The recipe

All seven ingredients still apply. The leverage is Guardrails (Ingredient #3). The station needs one hard rule: if the proposal aligns with Q3 roadmap priorities, route to the product lead. If it’s an existing vendor upsell, route to procurement. If it’s a cold pitch with less than thirty percent relevance to current business, archive with summary. These guardrails are load-bearing.

Context (Ingredient #2) is the second lever. The station needs to know your roadmap priorities, your list of current vendors, and what partnerships you’re actively exploring. Without context, all requests look the same.

Examples (Ingredient #4) teach the station what a “warm deal” looks like. A vendor pitch that aligns with priorities. A partnership that fills a real gap. Training (Ingredient #1) is the standard. You always route vendor upsells to procurement. You always flag integration proposals for the product team. The station learns the house workflow.

How to build it

  1. Define request types. New vendor pitch. Existing vendor upsell. Integration proposal. Partnership exploration. Consultant pitch. Don’t capture every variant. The main categories you actually see.

  2. Define your relevance criteria. Does the proposal align with your Q3 roadmap. Is it a capability you’re actively seeking. Is it from a vendor you’ve already evaluated. These criteria determine relevance score.

  3. List your current vendors and active partnerships. The station needs this context to identify existing relationships and upsells.

  4. Define the routing rules. Warm deal aligned with roadmap goes to the product lead. Existing vendor upsell goes to procurement. Cold pitch under thirty percent relevance goes to archive with summary. These are your guardrails.

  5. Pull ten examples from the last month. Real inbound requests. Some warm. Some cold. Some edge cases. The station learns what each category looks like.

  6. Set the triage thresholds. Sixty percent relevance plus roadmap alignment equals “route immediately.” Forty to sixty percent equals “flag for human review.” Below forty percent equals “archive.”

  7. Build the output format. Warm deals go to Slack with a summary and the product lead tagged. Cold pitches go to a spreadsheet. Edge cases go to a human queue. Define where each outcome lands.

  8. Test on fifty inbound requests. The station triages archived requests from the last month. You spot-check the routing. Any that landed in the wrong category need refinement of the guardrail.

What breaks it

  • Guardrails are fuzzy. “Relevant to the business” is too broad. The station flags everything as potentially relevant. Nothing gets filtered. The Chef’s inbox is still full.

  • Context is stale. The vendor list is outdated. The roadmap changed last month. The station routes based on priorities that aren’t priorities anymore. Relevant deals go to the wrong person or get archived.

  • Examples don’t represent your inbound. You pull five extremely warm deals and teach the station those are typical. Real inbound is ninety percent cold. The station learned to recognize a warmth level it almost never sees.

  • No feedback loop. The station archives a deal. A month later the Chef asks “why didn’t we hear about that vendor.” Nobody connected the archive decision back to training data. The station never learns which edge cases matter.

When it’s working

By week one, the station triages inbound. Eighty percent lands in the right bucket. Twenty percent needs human review because the station isn’t sure. By week two, the Chef is reviewing only the edge cases. The rest are routed automatically. By week three, the triage becomes invisible. Warm deals arrive on the product lead’s desk without the Chef seeing them. By week four, the system is so clean that when an off-roadmap request is flagged, the Chef actually reviews it because the signal is now trusted.

The signal that the recipe is sharp: a vendor arrives that fills a gap you didn’t know you had. The station flags it as an edge case. The Chef reviews and moves fast on a real opportunity because the triage caught it instead of burying it.

Monday Move

For the last two weeks, save every inbound vendor or partnership request. Twenty examples minimum. Manually triage them the way you’d like the station to. Document your routing decision for each. Show the station. Have it triage the next batch while you watch. Where does your decision differ from the station’s. That difference is what the guardrail needs to capture.

Dish 7 of 10 on the Operations Station. Build-note leverage: Guardrails (Ingredient #3).