"How much will it cost to integrate our shop with our ERP?" is the most expensive email a Polish SME ever sends. Not because vendors are expensive — because nobody, including you, actually knows what you're asking.
Typical scenario. The owner emails four IT vendors someone recommended. One question: "how much". A week later, four quotes come back. One at PLN 24k. Another at 48k. A third at 92k. A fourth at 180k — with a disclaimer that "this is a starting figure because the requirements are vague". The owner stares at the screen and has no idea what to do. Each vendor read "integration" differently.
That's not a vendor problem. That's a brief problem. And it's a problem you can fix in one afternoon, before anyone sends you a quote.
Why a "template RFP" doesn't work
Google "IT RFP template" and you'll get a 40-page document with sections on company history, mission statement, five-year strategy and a RACI responsibility matrix. For an SME, that's a waste of time on both sides.
The vendor doesn't need your company mission. They need answers to a handful of very concrete questions that templates don't actually ask. A two-page, honest answer to those questions is worth more than a forty-page template where 90% of the fields read "TBD".
A functional brief for an SME has to do three things:
- Describe the problem you want to solve. Not the technology you want to buy.
- Give the vendor hard numbers so they can estimate the work. Volumes, examples, scenarios — not slogans.
- Show how you'll judge whether it worked. What changes in the business when the project ends well.
That's it. Without those three, there's no money conversation — there's a wish auction.
The minimum worth writing down
For most integration and implementation projects in an SME, two to four A4 pages are plenty. The contents:
- Today (one paragraph). How the process you want to change looks right now. Briefly: who, in what system, how many times a day, how long it takes. One sentence on what hurts the most.
- The systems in play. Name, version, who the vendor or support partner is, whether there's an API, who knows the admin password. "Comarch Optima 2026, support partner: XYZ, API available, technical contact: Jan Kowalski (jan@...)". Without this, the vendor is guessing.
- What needs to change. Written in terms of daily work, not technology. "Shop orders must land in Optima within 15 minutes, no manual retyping, keeping the customer discount and payment method." Not: "let's build an integration microservice."
- Volumes. How many transactions a day? How many SKUs? How many branches? How many currencies? How many documents a month? These numbers drive the whole architecture. A vendor given numbers can estimate the work. A vendor given "quite a lot" will double the estimate just in case.
- Edge cases you don't want forgotten. What about prepaid orders? Returns? Foreign customers? Multi-currency invoices? List 5–10 situations that actually happen at your place — even rarely. Vendors price edge cases, because edge cases eat 60% of the implementation time.
- In scope and out of scope. "Scope: orders and stock levels. Out of scope: payment integration, loyalty programs, returns." If you don't write it down, one vendor prices two processes, another prices seven — and the quotes aren't comparable.
- How you'll know it worked. One or two sentences, measurable. "Manual retyping drops from 2 hours a day to zero; address errors drop by 90%." That isn't a formality — it's the acceptance criterion.
- Your constraints. Rough budget (don't keep it secret — vendors will ask anyway), timeline, your team's availability, dependencies on external ERP support.
If the document grows past four pages, that's usually a sign you're packing in things that should be a separate project.
One concrete example
At one of our clients — an 18-person plumbing supplies wholesaler in Lower Silesia — it started with that same classic email: "how much to integrate our shop with Comarch Optima?". The owner sent it to four firms. The quotes came back at PLN 24k, 48k, 92k and 180k.
They called us for a second opinion, because they couldn't tell whether the first one was a bargain or a trap. We sat down for three hours and wrote a 3-page brief. The contents:
- Today: two sales reps retype orders from the shop into Optima, about 60 orders a day, roughly 2.5 hours total. One address error a week.
- Systems: PrestaShop 8.1 (external hosting, admin access available), Comarch Optima 2026 (support: X, API available).
- Scope: orders (B2C and B2B), stock-level updates in the shop, customer records. Out of scope: payments (PayU stays as is), product catalogue (one-way daily export from Optima), returns and complaints.
- Volumes: 60 orders/day, 4,500 SKUs, 2 branches, 1 currency, EUR likely later.
- Edge cases: B2B orders with customer-specific discount, cash-on-delivery orders, no negative stock, made-to-order products (don't sync stock), shipping to a different address than the invoice.
- Success: reps recover at least 2 hours a day, zero manual retyping, address errors under 1 per month, no change to VAT accounting.
- Rough budget: up to PLN 60k, start in Q1, phased delivery.
The owner sent the same brief to the same four vendors. New quotes: 42, 48, 51, 54k. A spread of 29% instead of 650%. The two vendors who had been at the extremes (24 and 180) dropped out — one admitted they "hadn't noticed half the requirements", the other withdrew. The project landed at PLN 51k, on time, with two scope changes along the way, priced separately — no drama.
Time spent writing the brief: three hours. Net savings: hard to measure exactly, but at least four months of flailing and PLN 100k on the table. Nothing clever — someone finally asked a specific question.
What not to put in the brief
A brief becomes useless the moment it starts playing safe.
- "Modern, intuitive, scalable." These words say nothing to a vendor. Every one of them will answer "of course, our solution is modern". Replace them with numbers, processes and names.
- Specific technologies as a goal. "We want it in .NET 8 on Azure" makes sense if you have a real constraint (an existing in-house team working in .NET). It makes no sense if you copied it from a blog because it sounded fashionable. Describe the problem; the vendor will propose the stack.
- "Something like the competition." The vendor doesn't know what you see at the competition. Describe two or three concrete screens or flows.
- "We'll figure the rest out in workshops." That sentence in a brief means you're offloading the thinking. The vendor will price those workshops twice as high because they don't know what will come out.
If you don't know something, write it plainly: "we're not sure today whether this is in scope — please quote separately". It's honest and the quotes will be reasonable.
How to start in one afternoon
You don't need a treatise. A sequence that works:
- 90 minutes with the people who actually do the work. Not the board. Two sales reps, the accountant, the warehouse person — whoever is in the process. "What do you still do by hand? Where do mistakes happen? What would change your life?"
- 60 minutes writing it up as 2–4 pages. Not an RFP template. A plain Word or Markdown document with headings: today, systems, scope, volumes, edge cases, success, budget. Everyday language, no jargon.
- 30 minutes reading it to the person who will use the new system. "Does this describe your work?" If they say "yes, but X is missing" — add X.
- Send to three or four vendors. Not more. Five or more is a load you can't honestly process.
And the one question worth asking the vendor at the end of the brief, instead of a list copied from the internet: "What's missing from this brief for you to give a reliable quote?". A vendor who answers specifically is already showing they're thinking. A vendor who writes "all clear, quote attached" is already showing they're not.
If you don't know how to describe your project so the quotes don't diverge by an order of magnitude — half an hour with someone who's seen hundreds of these saves months of wish-auctioning.
A good brief doesn't describe the system you want. It describes the problem you have — specifically enough for someone from the outside to estimate what it takes to fix it.
Let's talk about your IT project before you send out quotes →