Skip to content
Notifications
Clear all

Step-by-step: building a simple negotiation script

4 Posts
4 Users
0 Reactions
0 Views
(@elliotk)
Trusted Member
Joined: 5 days ago
Posts: 51
Topic starter   [#14795]

Alright folks, let's talk about a practical problem I've hit a few times now. You're evaluating a new LLM provider, or a vector database, or some fancy RAG-as-a-service platform. The sales call goes well, you get the demo access, but then the quote lands in your inbox and... you have no idea if that number is reasonable. Is this their "standard" offer or the "we think you're clueless" price? 🤔

I got tired of just guessing or relying on gut feeling, so I started building out a simple, scriptable framework for negotiation prep. It's not about being adversarial, it's about entering those conversations with clear, data-backed benchmarks. The goal is to turn a murky, emotional process into a structured, fact-based discussion.

Here’s the step-by-step approach I now follow for any significant tool negotiation:

**1. Internal Requirement Mapping**
Before you even look at a price, you need absolute clarity on what you're buying. I break this down into:
* **Core Metrics:** What are the non-negotiables? (e.g., queries per second, embedding dimensions, max context length, guaranteed uptime).
* **Scale Tiers:** Define your usage at three levels: *Pilot* (next 3 months), *Growth* (next year), *Enterprise* (scaling out). This shows you're thinking long-term.
* **"Must-Haves" vs. "Nice-to-Haves":** Separate features critical for integration (e.g., LangChain compatibility, specific auth methods) from those you can live without initially.

**2. External Data Gathering**
This is where you calibrate. I create a simple spreadsheet for this.
* **Direct Competitors:** Get public pricing for 2-3 direct alternatives. Even if they aren't a perfect fit, their pricing model (per-token, per-embedding, per-user) sets a market expectation.
* **Indirect Benchmarks:** Look at analogous services. For a vector DB, maybe also check general NoSQL DB pricing. For an LLM API, compare not just OpenAI but also cohere, anthropic, and open-source hosting costs.
* **Community Intel:** This is where forums like this are gold. I note down any anonymized quotes or mentions of ballpark figures for similar scale. This helps spot outliers.

**3. Scripting the Conversation**
I don't read a script verbatim, but I draft key talking points and questions. This ensures I cover everything and don't get dazzled by sales talk. My script outline usually has:
* **An opening reaffirmation of interest:** "We're excited about [Tool X] and can see it fitting into our stack, particularly because of [specific feature]."
* **The data-driven pivot:** "As we're finalizing budgets, we're benchmarking a few options. Your quote comes in at [X] for our pilot phase. We're also looking at [Competitor A] at [Y] and [Competitor B] with a model of [Z]. Can you help us understand the primary drivers behind your pricing structure?"
* **Probing questions:** "How flexible is pricing based on commitment? Is there a difference if we sign an annual contract vs. quarterly? What's the typical discount for pre-purchasing credits?"
* **The "walk-away" alternative:** Have a credible fallback plan. "We do have the option to use [open-source alternative] with managed hosting, though we'd prefer a full-service solution like yours if we can align on value."

**4. The Follow-Up & Decision Matrix**
After the call, I immediately log their responses. Then, I score each option (including the fallback) on:
* Cost against our tiers
* Feature fit
* Implementation effort
* Vendor stability/roadmap

This process has moved me from feeling like I'm just haggling to having a structured evaluation. It forces you to do your homework and makes the negotiation a collaborative problem-solving session rather than a battle. What steps do you all take? Have you found particular data points or arguments that resonate with vendors in the LLM/vector space?



   
Quote
(@davidm78)
Estimable Member
Joined: 6 days ago
Posts: 64
 

That's a solid start. The core metrics point is key, but I'd push it one step further - you need to translate those into cost drivers for the vendor.

For example, with a vector DB, don't just list "embedding dimensions." Calculate your total expected vector storage per month. That's what their infra cost is actually based on. It turns your "requirement" into a shared understanding of the work their system has to do, which is a much stronger position to negotiate from.


Data doesn't lie, but dashboards sometimes do.


   
ReplyQuote
(@crm_hopper_2028)
Reputable Member
Joined: 3 months ago
Posts: 135
 

Yeah, the shift from "our spec" to "their cost" is the whole game. I try to do the same with CRM seat quotes, actually.

A lot of vendors price by "active users," but their internal cost is about API calls and data volume. So I'll map our forecasted workflows - automations that run, integrations that sync, reports that refresh - into a monthly API call estimate. When you show up with "our expected 200k API calls/month is a tier below your premium plan," the conversation immediately gets more concrete.

Have you found it's better to share those cost-driver estimates *before* the quote comes, or use them as analysis after you get the first number?


Still looking for the perfect one


   
ReplyQuote
(@cloud_infra_newbie)
Reputable Member
Joined: 4 months ago
Posts: 177
 

That's a great question, honestly. I'd lean towards after.

If I share my estimates first, I feel like I'm just giving them a target to price against. Maybe that's cynical?

But when I'm playing with AWS pricing for a project, I never tell them my budget. I figure out the cost drivers, then use that to understand their quote. If their first number is way off, then I bring my calculation to the table. It's more like fact-checking.



   
ReplyQuote