This article is illustrative. The company, the RFP, and both responses are invented to show the pattern. It is not a real client, a real bid, or a real competitor.
In How to Write an RFP for Software Development we argued that a software RFP should describe the problem and evaluate the partner, not collect a price for a scope that does not exist yet. That is easier to see with an example. Here is a made-up one, followed by two ways a vendor might respond to the parts that matter most: budget, scope, and unknowns.
The hypothetical RFP
A regional distributor with 14 locations, family-owned, roughly $60M in revenue, sends out an RFP. The summary, condensed:
We run on an ERP that handles inventory and invoicing well, but order entry is still phone and email. Customer service reps at each location key orders by hand. Errors are common, large accounts are asking for online ordering, and we have lost two of them to a competitor with a portal. We want a customer ordering portal that connects to the ERP, shows live pricing and availability by location, and lets customers reorder from history. About 400 active accounts would use it. Success means fewer order errors, faster order handling, and keeping our top 50 accounts. We have budgeted a range and would like the portal live before next year’s peak season. Please describe your approach, your team, relevant past work, and how you would handle risk.
That is a good RFP. It describes a problem, names the users, defines success in business terms, states a budget range and a real deadline, and asks for an approach rather than a fixed bid. Now the responses.
On budget
The weak response takes the top of the stated range, quotes it as a fixed price for everything in the RFP, and includes a payment schedule. There is no explanation of what drove the number, and no mention of what happens if something changes. It reads as confident. It was produced without a single conversation.
The strong response starts by confirming the range is workable for a first release, and then says which parts of the request it believes fit inside it and which may not. It explains that the biggest cost driver is the ERP integration, because live pricing and availability by location depends on how the ERP exposes that data and how clean it is, and nobody can know that from a document. It proposes a fixed-fee planning step, a VDP Sprint, to get the answer, and commits that the build proposal after it will come in as a fixed budget with controlled scope: budget and quality fixed, scope flexing, the client making the trade-offs. It notes that the value has to beat the fee and does the rough math with the RFP’s own numbers: two lost accounts and order errors across 14 locations against the stated range.
The difference is not which number is lower. It is that one response knows why its number is right and the other does not.
On scope
The weak response restates the RFP’s feature list as its scope, adds a few features the vendor likes to build, and attaches a timeline that lands before peak season with no room to spare. Every item is a checkbox. Nothing is prioritized.
The strong response separates the request into what a strong first release needs and what can wait. Reorder-from-history and accurate availability for the top 50 accounts are the first release, because those are what keep the accounts. Self-service for all 400 accounts, promotional pricing, and a mobile app are later phases. It says so plainly and explains the reasoning: get the portal in front of the accounts that are at risk, learn from them, then expand. It is honest that a first release before peak season is achievable only if the ERP integration turns out to be straightforward, and it says how that will be known by the end of planning.
A vendor that cuts your scope in the proposal is not being lazy. They are showing you they have thought about which parts of the request actually produce the result you named.
On unknowns
The weak response lists no assumptions and no risks. Or it lists generic ones: “client will provide timely feedback,” “client will provide access to systems.” Nothing specific to a distributor, an ERP, or 14 locations.
The strong response names the things it does not know and what it will do about each:
- Whether the ERP has a usable API for pricing and availability, or whether integration means working against the database or a nightly export. This decides the architecture and a large share of the cost. Resolved in planning by looking at the actual system with the client’s ERP administrator.
- Whether pricing by location is rule-based or lives in reps’ heads. If it is the second, the portal cannot show live pricing until the rules are written down. Resolved by sitting with two or three customer service reps in the first week.
- Whether the top 50 accounts would actually use a portal, or whether some of them want EDI or an emailed order form they can keep using. Resolved by talking to five of them during planning.
- What the customer service reps will do when order entry moves online. Adoption at 14 locations depends on them not feeling replaced. Not a software problem, but a project risk, and the response says so.
Then it explains how unknowns are handled once the build starts: a weekly look at remaining budget against remaining work, the client deciding the trade-offs, nothing cut or deferred without them knowing.
On the team and past work
The weak response lists the firm’s leadership and a logo wall. The people who would do the work are not named, and it is not clear where they are.
The strong response names the strategist, designer, and engineers who would be on the project, says they are in Texas and that no part of the work is offshored or subcontracted, and describes two past projects with similar shapes: a customer-facing system connected to an ERP, and a multi-location operations tool. Each with the size, duration, and the business result, plus a reference the distributor can call. It also describes a project that went badly, what was learned, and whether the client stayed.
On what happens after launch
The weak response ends at go-live.
The strong response describes maintenance and support as reserved hours billed monthly, with response times by priority written into the agreement, and hosting as cloud costs at pass-through plus a fixed monthly management fee. It notes that a customer-facing portal integrated with an ERP will need adaptive work when the ERP updates, and that this should be in the distributor’s budget from day one.
What the distributor should do with the two responses
Call both. The weak response may come from a capable team that simply answered the RFP the way most RFPs are answered. A 30-minute conversation will tell you quickly whether they understand the business or only the feature list.
Then ask the three questions from the RFP article. Do you communicate well with their people? Do they understand your problem? Do they ask good, smart questions? The strong response above asked several questions before it proposed anything. That is the tell.
The first step
If you are the distributor in this story, or anyone in a similar spot, the first step is a conversation, then a Deep Dive, then a fixed-fee VDP Sprint for a new system or a System Evaluation for one you already have. The typical budgets by type of project are on our pricing page. Book a 30-minute intro call and we will tell you honestly whether we are the right fit for the work.
Again: the distributor, the RFP, and both responses in this article are hypothetical, created to illustrate how proposals differ. Any resemblance to a real company or bid is coincidental.