Working at a public university I can say the recent move towards "contact us" pricing without including ANY pricing information has led to us not being able to look at many products. The way it works in my state is unless the vendor is already licensed with the university I'm not allowed to contact the vendor except to get a quote. If you start to give me a sales pitch asking questions about needs I am going to cut you off and hang up because its illegal for me to work with the vendor prior to an agreement in place. If your product is over 25K then I have to conduct an RFP which then means your company gets to make a pitch on paper and good luck convincing your product that I want is better than no name product I've never heard of from Oracle/IBM because they can undercut you because procurement has no clue what features/setup costs will be additional in their product that isn't in yours. They just go with what is cheaper.
On the other hand you give me up front on your website 1 user pricing I can take that public information and multiply it by the number we need, send it up the chain, make a convincing argument for sole sourcing, and then you will suddenly look like heroes with procurement because they were able to get it "so much cheaper" because I just multiplied what it cost for 1 * 30,000 (e.x.: number of students).
There's a reason prices are always hidden in jewelry store display windows. There's a little price tag on each item, but it's always tucked out of sight.
IMHO, there's pro's/con's to publicly listed pricing. There's definitely no hard and fast rule. Some con's to consider:
[1] It anchors prospects at certain price points (can be good and bad), [2] It might scare people off before you can value sell them and justify your pricing.
With enterprise SaaS, it entirely depends on: [1] what you're selling, [2] who you're selling to, and [3] the buyers' journey you're looking to accommodate / create.
I did not know they did this. But that is awesome. When trying to buy things even with a substantial budget in research, "contact us" was the most irritating thing - I don't need the damn up sell, but I do need to know whether you're thinking 10k or 50k.
I hate when the salesguys are then put off because you made them go through the apparently difficult process of generating a quote and then didn't buy their product.
If you had given me even a ballpark price up front I wouldn't have wasted your salesman's time!
Great points. I've also seen another pattern with per user or consumption-based systems...
When something is low enough to experiment with and still fall into the "petty cash" area, an employee can buy a little (or for a month) and test it out. If they're somewhat successful, they can expand it out to their immediate team, still with a tiny budget. As they prove out usefulness/value and expand their users/usage, obviously the cost goes up.
But by the time they have to "Get Approval" from someone really high up - like a VP or procurement group - they have X users or Y months of success. Selling it to the higher ups then becomes easier and a more likely sale.
That was pretty much the Yammer sales strategy, as I observed it. Infiltrate the customer by making it free and easy to sign up an organization, build a user base organically, without having to involve those controlling the purse-strings. Eventually, there's enough people using it that compliance and security becomes an issue, and the business sort of has to pay for the enterprise support to CYA.
It's an old hat trick. VP of MS SQL Server was telling the same story about MSSQL around 1999 at a division meeting. For on-premises products it's even more sticky.
Context: I work for a professional services firm. We sell, implement and customize enterprise software for large organizations, including public universities.
We NEVER provide pricing upfront. This is despite the fact that our software vendors have their prices listed clearly on their pricesheets. We know the price of a user license. But the first time our clients see the price is after we've performed our due diligence, learned the ins and outs of their business, and are sitting in front of their C-level people presenting the final proposal along with the Scope of Work document that outlines implementation details.
The reason we don't provide prices upfront is because it commoditizes the software and therefore our skills and services. It encourages clients to do an extremely shallow feature-by-feature comparison of the competing products. Doing that makes sense when purchasing commodities such as toothpaste or laundry detergent. You can look at two products at the shelf, compare their features, and go with the one that you think is better based on the messaging on the package ("25% more whitening power!"). But enterprise software is not like that. It is very complex and the price of the software is often only a small part of the final price, which is frankly unknown at the start of the engagement. That's why me giving you pricing information wouldn't help you one bit (in fact it could make you look bad to your superiors when the final price is several times higher than what you gave them originally).
Here's the thing: most of our clients LIKE the fact that we don't discuss price upfront. They understand that software is a different beast, and its value is dependent upon how well it fits into and/or can be molded into the needs of the business. Only very inexperienced purchasers push us for price, and over the years we've found ways of disarming or at least sidestepping them.
The bottom line is that companies who provide price upfront end up competing on price. And history has shown us that that's a race to the bottom.
"Here's the thing: most of our clients LIKE the fact that we don't discuss price upfront. They understand that software is a different beast, and its value is dependent upon how well it fits into and/or can be molded into the needs of the business. Only very inexperienced purchasers push us for price, and over the years we've found ways of disarming or at least sidestepping them."
I am not sure which side of that interaction to hold in more contempt ...
This carrot peeler has a variable value to customer, dependent on how much the customer will use it. We won't put the price out there until we know how valuable it is to our customer.
A better analogy is a toolbox. That's our combined product and service offerings. While each toolbox has ~50 different tools, most customers end up needing only a subset. Furthermore, they need each tool to be customized to their specific use case. So we use our technical skills and knowledge to modify those tools, package them and offer them as a customized solution.
That's why it would be silly for us to say "each toolbox costs X dollars." Each solution has a different price depending on what the customer wants to get out of it.
Your arguments are against providing exact pricing, that are rather obvious. The discussion seems to be about ballpark estimates. I'm not sure how to display this, but something along the lines seems reasonable: "Moderate installation at local high-school should fall under 1M, while a state University might get basic feature-set for 10M".
Large enterprises have whole departments for price-bargaining, but the smaller ones and especially public ones want to know the ballpark before issuing an RFP
By the sound of it, your pricing strategy makes sense for the kind of product or service you sell. By comparison, a company selling a single product should (in my opinion) have pricing available for at least their smaller tiers.
Professional services and a single SaaS product are very different.
The bottom line is that companies who provide price upfront end up competing on price. And history has shown us that that's a race to the bottom.
As a counterpoint to this, my cofounder and I have been very successful with our own security consulting firm with the opposite philosophy. We have not found transparent pricing to be an obstacle in landing lucrative clients. I also haven't seen any race to the bottom of "commiditization" in our industry. One of our closest competitors also publicly lists weekly rates.
I don't know that they care one way or another. It's not as though we champion transparent pricing in our sales pitch - it's simply one more available piece of information on our website. Potential clients still need to contact us, they just know what to expect. We haven't found that we have pressure to reduce our prices or compete on price as a result. Granted, we cater to more YC companies than we do Fortune 500s, but we still serve both, and the firm does very well.
The vast majority of our work comes in through referrals, which probably changes things a bit. I think there is merit in either approach, enough that it's not fair to say one definitively causes this or that as a result.
Consulting rates and enterprise software pricing are two different beasts, especially when hosting infrastructure is involved...
On top of this, enterprise buyers are not always going to be sophisticated enough to determine whether their business requirement means they need module a or b or feature x vs. y from a random enterprise suite.
Commoditization is not going to be an issue in highly technical fields such as security consulting, which is why your approach works for you.
In our field though, there are a lot of competing products, and a lot of them are either free or very cheap. And at a high level, they have similar "features" and "benefits". But once you get down to the nitty-gritty, there are tons of differences. That's why we spend a lot of time and effort educating our clients on those differences. We have to demonstrate the value first before providing the price in order to avoid sticker-shock.
>Here's the thing: most of our clients LIKE the fact that we don't discuss price upfront.
Sorry, but absent reliable data, I'm calling BS here: I've never, ever met someone who likes having to call some random salesman to get a price and figure out if the service is even within a order of magnitude of their budget.
In fact, most people I know detest those kinds of games.
I'm bugged if I have to hop on the phone to talk to someone about something I saw on their website. That's about as un-Internet as you can get. You might as well ask me to send you a postcard.
After a few interactions with enterprise "call us" pricing that went crazy and one where the quote went from £10k per seat to £1.5k per seat (for the exact same fit out), I always feel like I'm about to get screwed when I pick up the phone.
Totally understand and agree with your observations as a pro services firm. That is the funniest part of the university I work at - say your company implements a solution for us like Product X. Well then all the sudden we can explore your ENTIRE product/service catalog with you without consequence because we have an agreement with you (for whatever). So even though you sold us product X we can also look into service Y where I'm not as concerned with cost but getting the right one. To say however they LIKE not discussing price upfront seems a bit disingenuous - yes I would want to discuss the service first but I am going to want an idea of what its going to cost to put that into my budget/grant/etc to see if it fits, especially if funded by the state. My university may be different though as I've found out many times over.
I imagine getting that first contract though wasn't easy - as that initial connection had to likely come through an RFP? and what is the ratio of RFP submission to actual customer?
>>yes I would want to discuss the service first but I am going to want an idea of what its going to cost to put that into my budget/grant/etc to see if it fits
That's the thing though: it's an extremely wide range. For example, anywhere from $25,000 to over $1,000,000. It's impossible to say upfront whether it will fit your budget.
The reason we take a consultative approach (as opposed to a traditional sales approach and leading with the price) is because we want you, the customer, to control the scope of the project. We work with you to understand your requirements, then prepare a preliminary proposal and SOW with the price. You can then say, "well, this is a bit out of our budget, but maybe we can postpone features X and Y until the next phase" and we go back and forth until the final scope and associated price are acceptable to you.
I can't disclose our ratio of RFP submission to customer. But the thing about RFPs is that they are rarely objective. In the vast majority of cases, the client's preferred vendor helps the client write the RFP. And in a lot of cases we end up being that vendor, because the clients trust us after seeing our methodology.
That's what many people think, but it's actually not true (at least not in the states I've worked in). There's a cottage industry that provides advice on how to navigate through the RFP process, and a lot of the advice is based on controlling what goes into the RFP when it is written. Take a look at this set of slides:
The most important thing to understand about RFPs is that they aren't designed for making the "most fair" selection. They are designed for making the "safest" selection. An RFP is basically a CYA (cover your ass) mechanism for the procurement team. That's why collaborating with preferred vendors when the RFP is being written is a very common practice. Teams writing the RFPs rarely have the subject matter expertise necessary. So they receive help (which is a good thing).
I wonder if withholding pricing information is simply a negotiation tactic that exploits the sunk cost fallacy. If not, funnel conversion rates should be invariant of the stage at which pricing is disclosed, right?
> But enterprise software is not like that. It is very complex.
That's exactly why SaaS disrupt traditional enterprise on-premises software - too complex (installation, user interface), too expensive upfront.
If the software requires no 3 weeks installation phase, no handbook nor training and costs a fraction of the usual 100k to 1m, like $200/host/month, then there is often a clear winner.
I work for an SaaS startup selling into the financial sector. We started out with a different kind of pricing model, based on volume; a simple formula based on data throughput. It didn't survive our first sale.
Selling to large entities, even SaaS, still involves negotiation. Often the large customer wants some key features; sometimes it's a checkbox feature, sometimes it's to disarm antibodies inside the organization, sometimes it's something they actually need for a business requirement. That work needs to be priced in.
And there's the other side of it: different organizations get different amounts of value from our software. If we don't charge organizations who get more value more money, we're leaving profit on the table. Even shrinkwrapped software back in the day had segmented offerings to capture more value. And when you're selling to large organizations, which will necessarily involve multiple salespeople and a bunch of meetings (i.e. scope for fine-grained segmentation without confusing proliferation of products), if you don't charge different prices to different organizations, you're an idiot.
If anything, this way of selling is better for smaller organizations than the segmented approach. Even if we can't charge more, all customers at least get the same product.
That's not to say that volume and data throughput doesn't form a part of the price calculation. But it's a multiplier where the base price is based on the value delivered, which is business dependent.
Even in the private sector, I assume that "call for pricing" is another way to say "If you have to ask, you can't afford it", and I often skip those vendors if I can't find even ballpark pricing - just tell me if it's $5 a seat or $500 a seat we can work out the exact pricing later.
My takeaway - have a gov/edu pricing section that is clear, RFQ friendly, aimed at internal "champions" and absolutely unconnected to the prices I will charge enterprises
It's a problem for the university if the procurement rules really are that explicit and dumb. I mean, just imagine what you'd get if you need custom work done and had to put the phone down on anybody that has the temerity to try to discuss scope with you.
"We had to turn down all these companies with relevant expertise because they wanted to talk to us, but it's OK, we've found a price for this guy on Elance and he's $5 per hour. We're not sure how long he'll take but he's definitely the cheapest option."
> Enterprise customers just want to buy. Jason says
> that price doesn’t matter for enterprises. More than
> 80 percent of the time, they just want to get set up
> with a solution as efficiently as possible. Price
> comes after features.
That's ... misleading.
Software is often not just purchased by an enterprise all at once. More frequently, some team with a small budget decides it would be useful to use tool X. Someone with a company card is put upon to purchase a license for the 5 people in the team. Other teams get interested, and start using it. Costs get to the point where it needs to be sent to procurement, at which point, it becomes an enterprise software deal. But it didn't start that way - it started with some small team who are price sensitive trialing it...
This internal viral growth strategy is actually a disruptive methodology to traditional sales methods. Most companies did not buy this way traditionally. Startups and hackers often think this is how software is sold to the Fortune 500 but for the most part the CTO or someone in her office has already been woo'd and large enterprise agreements are in place.
When a product like this begins to gain traction inside a large company it usually sparks a response from an internal immune system of champions for the entrenched software companies. These people are trained to explain why the new product cannot "scale" to enterprise needs and spread FUD about the new product.
From my experience if the new product can keep it's prices very low the price pressure can usually win out in the long run. Paying an army of salespeople to take everyone out for steaks can be expensive and in the end that cost is put back on the customer.
You can see the incumbents (IBM, CA etc) trying to figure out how to deal with disruption caused by companies spreading with this more viral model. (Amazon AWS, Atlassian etc).
Fun times out there it's interesting to see how the world is changing.
It's funny that you mention Atlassian. We tried to get Jira for a team I was working on a few years back and were told no by the IT department. They said we should use an internal system that someone had hacked together in a satellite office. Then they tried to charge us $100k for that.
Deals at big companies always have more moving parts than just plopping down a credit card. There's some manager who wants to put people under him to manage the system. Someone else who wants to boost their status by pumping up their budget, etc...
I'm not sure where that thinking ("...Enterprise customers just want to buy...") comes from. It happens a lot where I am asked to "come up with a plan, in broad strokes and ballpark figures, by Thursday" and if I can't come up with a cost for a service, I won't even consider it. I just don't have the time to spend to wait for a rep' to get back to me.
I think that's the minority of most Enterprise software deals, though. Typically it's sold to someone completely removed from the process (e.g., ServiceNow being sold to the CTO).
I think that depends on if it's CIO-domain (email, calendering, desktop control) or CTO-domain (dev tools etc). The latter I've rarely (but not never) seen foist upon uninterested developers.
Surprisingly often, it also comes down to departments that have budget surpluses at the end of their fiscal year. A lot of companies still seem to be locked into that use-it-or-lose-it approach to budgeting, so I've repeatedly seen software purchased, and then never even downloaded, much less installed.
I was merely stating that the OPs observation is true with what GP said. I agree that it often won't get that far - I've often passed over tools that my employers would have bought because I couldn't access pricing without contacting sales and didn't want to ask for something without knowing what it will cost.
The title is somewhat misleading because only 48/250 had actual pricing pages, the others had what really amounts to "contact us" pages for their sales teams. Fortunately it's still an informative read, and even 48 pages are enough for meaningful discussion of pricing pages. The original post has additional infographics at the end of the article (a helpful way to reason about ideas contained within after going through it all in text): https://www.process.st/2015/12/saas-pricing-pages/
As a consumer I often feel like contact-style "pricing" pages are a way of trapping customers into a hard-sell. Granted some pricing structures are complicated out of necessity, especially those where usage plays a significant role in the cost to the provider (substantial bandwidth transfer, hardware/setup, human resources). More often than not I immediately abandon any such service if contacting for pricing is the only option. It was surprising to see 80%+ (202/250) of companies didn't list their pricing because my personal real-world experience feels like the inverse.
The article discusses the reasons for the contact-only approach, which boil down to preventing biases for enterprise customers. While that's understandable in some situations, not all SaaS is intended to target enterprise customers. It goes on to consider pros/cons of the multifaceted concept that is tiered pricing. If read this much of my comment but not the article, go read it now!
(A couple typos for the author: "boost revenue"→"boosts revenue", "Abscense"→"Absence")
The article seems a bit simplistic in the way it draws conclusions. Still I wonder why so many companies picked the most counterintuitive solution.
Edit: I've come to believe that enterprise customers are likely to have different, more strict requirements compared to SMB customers. This is probably why, for enterprise sales, it could make more sense to approach the pricing part in a more traditional way.
At Userify[1], we just made our primary product (user and SSH key management for cloud servers) completely free. We're charging incrementals for feature upgrades, faster sync (from 3 minutes down to 10s), etc.
On the other hand, this hasn't slowed down our enterprise sales cycle at all; in fact, it seems to have sped it up, with five enterprise deals in the pipeline right now.
However, this approach is risky and it's really hard to get the balance right; companies that have raised rounds might have to answer to investors. Still, sometimes it's worth prioritizing long-term growth over short-term revenue.
My view is that we should always have something free or very cheap for the smaller technologist/hacker/startup. They tend to bring their favorite solutions to other larger companies. Goodwill is one of the best growth factors.
Trying to scroll your website on a Mac trackpad causes it to jump around like crazy. Did you install some too-clever-for-its-own-good Javascript? (Has anyone else noticed this is an increasing - and annoying - trend?)
As an MBP trackpad user, I can't think of a more annoying web trend. To the point that I'm thinking of finding a way to disable this kind of behaviour and make a Chrome extension to block this thing everywhere.
Web developers just shouldn't ever try to fight the useragent.
If you find yourself trying to "fix" a UI/UX in the browser itself, stop.
I don't care if you want 300ms faster clicks on mobile, or to force smooth scrolling in chrome, or to hijack right click for your sharing stuff, or whatever.
You are breaking stuff trying to do those things, and it's ruining my experience on your site.
Safari user here, not noticing any scroll highjacking currently. Thank you. Your web site still does other awful things, but at least you've banished the most obnoxious, most instantly-want-to-close-the-tab sin.
Okay, well, first off, keep in mind that I'm a curmudgeon when it comes to the web and generally dislike more things about the modern web than other people, so I don't really fault you for just writing me off and ignoring all of this. That being said, here are, in my opinion, the remaining awful things about your web site.
1. The loading animation. I did not wait for your page to load in order to wait for your page to load. Also, if I have JavaScript disabled or JavaScript breaks for some reason, all I can see is that loading animation - absolutely zero of your front page content.
2. The text scrolls up into the middle of the page. Nothing should move on your page without my permission.
3. The fading in/out red text. See 2.
4. The spastic dots/lines following the pointer around above the globe image. See 2.
5. As I scroll, the bar at the top hovers over the page content. This breaks PgUp/PgDn behavior, as it covers content, as the height of the page no longer matches the amount of the page that's actually legible. Also, the bar changes size and color. See 2.
6. You're using a custom font. Are the perfectly fine fonts already installed on my system not good enough? Must you really waste my bandwidth and slow down your page loading time for the sake of your brand? Fortunately, you're using one hosted by Google; I have `127.0.0.1 fonts.googleapis.com` in my hosts file, so it actually didn't effect me. I could still see it trying to happen when opening up Web Inspector, though.
7. I'm seeing your total front page weight as 1.82MB. global_map2.png is 512K. essentials.css is 468K - Jesus, that's a lot of CSS. Even the HTML file is 111K - apparently because you're inlining jQuery, on every page, forcing my browser to redownload it for every page load when it could just grab it from cache after the first one.
That's all I'll say for now. I need to get back to work. Hopefully this is of some help, though.
EDIT: Just to balance things out, here's a good thing - you're bouncing users to the HTTPS URL for your site, even when we're not logged in (or about to). Good!
Thanks. :) I'm on Linux Chromium and it worked fine for me, but maybe it was Safari not liking the accelerated scrolling plugin. (Off-topic, why are so many site themes bloated with bells-and-whistles..)
You need a better layout for your API documentation. It's a wall of text. Add in a navigation sidebar, or better yet just copy Stripe.
Also the how-tos are too longwinded. You could probably reduce the quantity of prose by 50% or more. e.g. the very first paragraph "Getting logged in is easy and takes only a second..." is waffle and missing a vital opportunity to explain how the damn thing works!
There's an open source project called Slate [1] which is basically a static site generator for API docs you might consider which looks like Stripe's API docs.
> What can this teach us about SaaS pricing pages?
> Even the most successful SaaS companies in the world don’t conform to the ‘best practices’ laid out by conversion specialists.
Not sure I agree with this conclusion. Obviously you should test to see what works for your audience but imo, the whole point of comparing how each company does X is to extract the most common patterns people can use as solid starting points.
The article would have been a lot of more useful if it listed at the end the most common elements SaaS pricing plans share like 63% offer a free trial. It's a waste of time to try to design from scratch instead of referencing what most of your peers are doing.
Also, just because some SaaS companies don't conform to the best practices, it doesn't mean that their way necessarily converts better. Maybe they would convert more if they did certain best practices.
We chose not to do so, but I can tell you why you'd move to non-public pricing (at least have a non public pricing tier).
As much as people love to blame vendors, this is mostly due to dysfunctional nature of the large enterprise buyers. They are addicted to discounts. First the buyer contacts you asks for one then after everything gets said and done done, procurement gets involved and ask for more discounts (seen as their job). Having listed pricing becomes a problem when going through such process, so most vendors either choose not to publish their prices, or have a tier for the enterprise that is not published.
We had three or four plans, the last being "enterprise/contact us". We found that we were only making money on enterprise customers and hence the price page became just "contact us" - so we took the page away. I expect that MANY SaaS vendors go through the same pivot.
I'm a customer acquisition consultant for B2B software co's, so I've been involved in a fair amount of decisions around this. Without sharing specifics, I can objectively say that requiring prospects to contact you to learn about pricing will...
1. ... Weed out non-serious prospects such as students, freelancers, small businesses, etc.
2. ... NOT deter serious prospects (enterprise users). They are used to this process and even expect it.
Is serious/non-serious so binary?
My biggest issue is I wouldn't want to commit anything, or give too much information away just to get a ballpark figure. I'd also assume that I'd be aiding price discrimination - There is no problem having up-front ballpark pricing and a 'contact us' link.
Hell, just having a high ballpark figure will weed out students and small businesses.
> There is no problem having up-front ballpark pricing
There certainly is, and it's a bigger problem than potentially turning away people who are uneasy about sharing contact info. Just to name one: A SaaS company may be willing to undercut a competitor's price for a sufficiently big prospect, but advertising a high price at the outset may turn that prospect away before you have a chance to talk to them.
After going through the article I would have really liked to see what the average prices for these companies are, even though only 48 out of the 250 SaaS companies published pricing pages.
On average there were 3.5 pricing options per company, with the highest priced option leading towards a "Contact Us" 38% of the time. I feel like the companies that published prices were not targeting enterprise level companies (just a hunch), so seeing the range of their prices could be a very interesting guide for pricing SaaS outside of enterprise sales.
For enterprise SaaS an analysis of the Lead Gen forms for the other 202 companies would be very interesting.
> After going through the article I would have really liked to see what the average prices for these companies are
Seeing as how the services they provide will be so different, would it really be a relevant number?
Even then, how would you calculate it? The average of each company's lowest price plan, or the average of the average of each company's plans, or the average per-user price, or…?
Pretty good article overall, but some of the data is conflicting:
> HubSpot’s fantastic article about decision fatigue included a study which showed customers who were presented with six options instead of 24 were 10 times more likely to buy.
> Sliding scales allow customers to be ultra-specific with their needs and pay for only exactly what they’re going to use. Plus, according to Peep Laja, giving users something to play around with will keep them sticking around for longer and subconsciously soaking in the details and pricing of your product.
Here's a plan B based on several experiences with enterprise SaaS:
Start with something that isn't awful. Get it up early. A/B test that crap out of out.
Keep it simple -- Only have one unit of measure (UoM) or feature differentiator at first. Having multiple points of differentiation or UoM leads to confounded experimentation. Try to add more " per's " over time :)
You can take forever debating this stuff. Data is the only guide.
> Just 4% of companies offer pricing on a sliding scale
Interesting. As a consumer I would like a slider, but as a company one wants to upsale the user a higher priced plan. Recently, I saw several new SaaS companies that have a slider.
Actually, slider-pricing is often a bad idea for B2B-SaaS tools. Simple reason: Almost every purchasing process in almost every company (other than software startups) is expecting a fixed, monthly rate. Put yourself in the mind of your champion: Do you want to push a deal like any else through management, procurement, etc (which is already hard enough), or do the same process every month for a slightly different price point?
I'm not sure there's a takeaway from all this. My sense is that pricing is still really poorly understood. The one key thing to understand about product configuration and pricing is that it depends a huge amount on how flush the customer is with money. Bootstrap/unfunded/mom-pop will pay zero or very little. A company with some friends/family or angel/seed funding can spend a little bit. A fully funded or larger company can spend a lot.
On the other hand you give me up front on your website 1 user pricing I can take that public information and multiply it by the number we need, send it up the chain, make a convincing argument for sole sourcing, and then you will suddenly look like heroes with procurement because they were able to get it "so much cheaper" because I just multiplied what it cost for 1 * 30,000 (e.x.: number of students).