Embeddings API Selling to the ML Engineer — 60-Min Training

The two paths reps actually choose between

Every embeddings deal splits into one of two motions, and the training's first job is making reps name which one they're in before the second call.

Motion A — the retrieval-quality replacement. The prospect already has a RAG or semantic search system running on an older model, an in-house TF-IDF/BM25 stack, or a first-generation embedding endpoint. The buying trigger is a complaint: users say search "doesn't find the obvious thing." The ML engineer already has, or can build in a day, a labeled relevance set — a few hundred query/document pairs where they know the right answer. This motion is won on measured lift. It is lost by talking about model architecture.

Motion B — the greenfield build. The team is standing up retrieval for the first time, usually attached to an internal assistant or a customer-facing search feature. There is no baseline, no labeled set, and often no clear owner of the budget yet. This motion is won on time-to-first-working-prototype and on the surrounding surface area — client libraries, batch endpoints, rate limits, how easy it is to re-embed a corpus when the model version changes. It is lost by demanding a benchmark the prospect cannot produce.

The distinction matters because the same rep pitch kills the opposite motion. In Motion A, offering to "help design your evaluation" reads as stalling — the engineer already has an eval and wants a number. In Motion B, opening with NDCG@10 makes the rep sound like they're asking the prospect to do homework before earning the right to a trial.

There is a third case worth naming in training even though it rarely closes fast: the team evaluating self-hosting an open-source model (the BGE family, E5, and similar Hugging Face options) against a hosted API. This is not really a competitive loss to another vendor; it's a build-versus-buy decision driven by data residency, per-token cost at very high volume, and whether the team has GPU capacity and MLOps staff to spare. Reps who argue open source is "worse" lose credibility instantly — many open models score competitively on public benchmarks. The honest wedge is total cost of ownership: inference hardware, on-call rotation, re-embedding jobs, index rebuilds, and the engineer-hours that get pulled off product work.

Adjacent motions follow the same shape. A rep who learns this framework transfers it directly to reranker APIs, vector database selling, and fine-tuning platforms — all three are evaluated by the same person, on the same corpus, with the same "prove it on my data" reflex.

How to decide which motion you're in

The qualification sequence below is what the 60-minute session drills, and it should take under ten minutes on a first call. The goal is not to disqualify aggressively — it's to route the deal into the right proof structure before anyone burns a week on the wrong trial.

Open with the corpus, never the product: *"Walk me through what you're embedding — document types, roughly how many, and how often they change."* Corpus shape drives everything downstream. A million static PDFs is a different sale than a hundred thousand support tickets that churn daily, because re-embedding cost is a recurring line item in the second case and a one-time cost in the first.

Then establish whether an eval exists. *"If we swapped models tomorrow, how would you know it got better?"* An engineer who answers immediately with a metric is Motion A. An engineer who says "we'd eyeball a few queries" is Motion B, and the rep's job shifts to helping them stand up a lightweight eval — twenty to fifty labeled queries is enough to be directionally useful, and offering to help build it is a genuine value-add rather than a stall.

Third, find the money. Embeddings spend is usually small relative to generation spend in the same application, which cuts both ways: it's easy to approve, and it's easy to deprioritize. Ask what the total AI budget line looks like and whether embeddings sit inside it or beside it.

One more branch belongs in the drill: whether the prospect is volume-constrained enough that self-hosting genuinely wins. Reps should be trained to concede this out loud when it's true. *"At your volume and with your residency requirements, an open model on your own hardware is a defensible call — here's the cost line that would flip it back."* That sentence buys more credibility with an ML engineer than any competitive slide, and it keeps the door open for the reranking or generation deal that usually follows.

The numbers behind each path

This is the section reps most often skip and most often need. The training should force everyone to build the math live, on a whiteboard, using the prospect's actual corpus size.

Corpus-to-token math. Start from documents, convert to chunks, convert to tokens. A typical chunking strategy lands somewhere in the 200–800 token range per chunk, with overlap adding perhaps 10–20% on top. A 100,000-document corpus averaging four chunks per document produces roughly 400,000 chunks; at 500 tokens each, that's about 200 million tokens for a single full embedding pass. Reps should be able to do this arithmetic without a calculator, because doing it on the call is what earns technical respect.

Initial pass versus steady state. The one-time backfill is usually the scary number in the room, and it's usually not the number that matters. Steady-state cost is driven by two flows: new and updated documents, and query embeddings. Query volume is often underestimated — every search request embeds the query text, and a high-traffic application can generate more query tokens per month than the entire document corpus. Ask for queries-per-day and average query length, then compute both flows separately.

Re-embedding risk. Model version changes force a full re-embed of the corpus. This is a real cost the ML engineer will raise, and reps who preempt it win trust. Cover what the vendor's version-deprecation policy is, how long old versions stay available, and whether the vendor offers batch pricing for large backfills. If a vendor offers discounted asynchronous batch processing, that is exactly where it applies.

Dimension and storage trade-offs. Embedding dimensionality drives vector database cost, not API cost. Higher-dimensional vectors mean more index memory and slower search. Several current models support truncating dimensions with modest quality loss — an engineer can cut storage substantially and measure the retrieval hit on their own eval. This is a genuinely useful conversation because it saves the customer money in a different budget line, which is the most credible thing a seller can do.

Where the price sensitivity actually sits. Embedding endpoints are dramatically cheaper per token than generation endpoints — often by an order of magnitude or more. The practical consequence for reps: raw per-token price rarely decides the deal on its own. What decides it is quality on the customer's corpus, latency at their concurrency, rate limits that survive their traffic spikes, and whether the contract can absorb a re-embedding event without a budget re-approval. Train reps to stop leading with price and start leading with the cost *shape*.

Discount realism. Do not train reps to promise multi-year discount ladders they cannot authorize. The honest posture: annual commitments and volume tiers are normal, published rate cards move less than in traditional SaaS, and the largest concession available is usually commitment flexibility — the right to shift committed spend across endpoints — rather than a headline percentage.

Sequencing a proof of concept that survives procurement

The POC is the deal. Everything before it is scheduling and everything after it is paperwork. Here is the seven-day structure the training should hand reps as a one-page artifact.

Day 0 — scope and access. The customer's engineer installs the client library and gets an API key. The rep does not touch the environment. Agree in writing on three things: the corpus subset being tested, the metric, and the threshold that counts as a win. Vagueness here is what turns a seven-day POC into a seven-week one.

Days 1–2 — baseline first. Run the existing system on the eval set and record its score before touching the new model. Skipping this is the single most common POC failure, because without a baseline any result is unfalsifiable and the engineer knows it.

Days 3–4 — embed and index. Full pass on the test corpus, indexed in whatever vector store the customer already runs. Notably, this step surfaces integration friction that has nothing to do with the model — batch endpoint behavior, rate limits, retry semantics, dimension mismatches with an existing index. Reps should treat friction here as a finding to solve visibly, not a problem to hide.

Day 5 — measure and inspect. Score the eval set. Then do the thing that actually moves engineers: pull the twenty queries with the largest rank change, in both directions, and read them together. Wins explain themselves; regressions explain what to tune. An engineer who sees a rep willingly examine the losses will believe the wins.

Day 6 — tune once, not forever. Chunking strategy, query prefixes or task-type instructions, and whether the model has a distinct query-versus-document encoding mode. One tuning round, one retest. Endless tuning signals the model doesn't win on its own.

Day 7 — joint readout. ML engineer, data lead, and the budget owner in one room. Present three numbers: the lift, the monthly token cost at steady state, and the storage delta from any dimension change. Send the proposal the same day.

Two sequencing notes that reps consistently get wrong. First, do not let the POC expand to include reranking, generation quality, or agent behavior — those are separate deals with separate evaluations, and bundling them means a single unrelated failure sinks the embeddings result. Second, get the security and data-handling review started on day 0 in parallel, not on day 8. Whether corpus content is retained or used for training is a gating question at most enterprises, and discovering it late costs weeks.

What the 60 minutes should actually look like

Time is the constraint, so the agenda has to be brutal. A workable split: five minutes on why this buyer is different, fifteen on the qualification sequence with a live role-play, fifteen on the corpus-to-token math done on a real prospect's numbers, ten on the POC structure, ten on incumbent and open-source objections, five on renewal setup.

The single highest-value fifteen minutes is the math, done live. Give every rep a real account from their own pipeline and make them produce a token estimate and a monthly steady-state number in front of the group. The ones who can't do it without a spreadsheet will discover that in the room instead of on a call.

The role-play should be adversarial in a specific way: have the manager play an ML engineer who answers questions with benchmark numbers and asks about training-data provenance, context length limits, and whether the model handles their language mix. Reps who default to feature recitation get stopped and reset. The correct response to nearly every hard technical question in this sale is a variant of *"I'd rather not guess — let's measure it on your corpus"* followed by an actual date.

Close the session on renewal mechanics, because embeddings renewals are set in month one. Three things to lock at kickoff: an agreed steady-state volume forecast so the finance owner isn't surprised, a named champion who receives a quarterly usage-and-quality readout, and a written expectation for what happens when the vendor ships a new model version. That third one is the sleeper — the customer who gets blindsided by a deprecation notice churns, and the customer whose rep warned them six months early expands.

Finally, teach reps where this deal leads. An embeddings customer is a natural buyer of reranking, a vector database, evaluation tooling, and eventually a generation contract. Selling the first one well, with visible honesty about where the product loses, is what makes the next four conversations short.

Related questions

How large does a labeled relevance set need to be?

Twenty to fifty well-chosen queries with known correct documents is enough to see directional differences. A few hundred gives stable comparisons. Perfect labeling matters less than consistent labeling — the same judge applying the same standard across both systems.

Should the POC use the customer's production vector database?

Yes, whenever possible. Testing in a throwaway store hides dimension mismatches, index configuration issues, and latency behavior at real concurrency. Those integration details are where greenfield deals actually stall.

How do you handle a prospect leaning toward open-source self-hosting?

Concede where it's genuinely stronger — residency control and per-token economics at very high volume — then quantify the operational cost they're absorbing: GPU capacity, on-call coverage, re-embedding jobs, and engineer-hours diverted from product work.

What's the most common reason an embeddings POC produces a flat result?

Chunking, not the model. Chunk size, overlap, and whether document titles or headers are included in the embedded text often move retrieval scores more than swapping model families does.

Who signs the contract when the ML engineer has no budget?

Usually an engineering or data leader with a platform budget line. Find them by call two and get them into the day-seven readout — a technical win with no budget owner present converts slowly and renews worse.

FAQ

Is a public benchmark leaderboard useful in this sale at all?

It's useful for shortlisting and useless for closing. Leaderboards tell an engineer which three models are worth testing; they say nothing about performance on a specific corpus with domain vocabulary, unusual document structure, or a particular language mix. Train reps to reference benchmarks as a filter and immediately pivot to corpus-level measurement.

How should reps talk about latency?

In terms of the two flows separately. Document embedding latency mostly doesn't matter — it's a batch job. Query embedding latency sits directly in the user-facing request path and adds to every search. Ask for the application's latency budget, then measure query embedding time at the customer's expected concurrency rather than quoting a single-request number.

What technical questions should every rep be able to answer without escalating?

Maximum input length per request, how the model handles inputs that exceed it, whether query and document encoding differ, supported output dimensions, batch endpoint availability, rate limit structure, and the data retention policy. Anything deeper is a legitimate solutions-engineer handoff and should be framed that way rather than guessed at.

How do you keep a POC from expanding into a full RAG evaluation?

Write the scope down on day zero and name what is excluded. Retrieval quality is the test; answer quality, reranking, and agent behavior are not. If the prospect insists on end-to-end evaluation, agree — but hold the embeddings comparison as an isolated measurement inside it so a generation-layer problem doesn't get attributed to the wrong component.

What's the right cadence after the contract is signed?

Monthly for the first quarter, then quarterly. The recurring agenda is three items: actual versus forecast token volume, retrieval quality against the original eval set re-run on current data, and any upcoming model version changes. That last item is the difference between a renewal conversation and a churn conversation.

Does this training transfer to adjacent AI infrastructure products?

Almost entirely. Reranker APIs, vector databases, and evaluation platforms are sold to the same buyer with the same "measure it on my data" reflex. The corpus-first discovery, baseline-before-test discipline, and joint technical-plus-budget readout structure carry over with only the metric changing.

Sources

• https://platform.openai.com/docs/guides/embeddings
• https://docs.cohere.com/docs/embeddings
• https://ai.google.dev/gemini-api/docs/embeddings
• https://huggingface.co/spaces/mteb/leaderboard
• https://huggingface.co/BAAI/bge-large-en-v1.5
• https://en.wikipedia.org/wiki/Discounted_cumulative_gain
• https://www.pinecone.io/learn/vector-embeddings/
• https://weaviate.io/blog/vector-embeddings-explained
• https://docs.anthropic.com/en/docs/build-with-claude/embeddings

Related on PULSE

• [Vector Database Selling to the ML Platform CTO — 60-Min Training](/knowledge/st408)
• [LLM API Selling to the Head of AI Engineering — 60-Min Training](/knowledge/st407)
• [Fine-Tuning Platform Selling to the ML Platform Lead — 60-Min Training](/knowledge/st413)
• [Computer Vision API Selling to the ML Platform Lead — 60-Min Training](/knowledge/st419)
• [Speech-to-Text API Selling to the Voice Platform Lead — 60-Min Training](/knowledge/st420)
• [AI Translation API Selling to the Localization Lead — 60-Min Training](/knowledge/st425)