Why the first email matters more than it should
A two-line enquiry produces a two-line answer, or more often, a calendar link. That is not laziness on the vendor's side; it is arithmetic. A firm that cannot tell whether your project is a $20,000 script or a $400,000 platform has only one move available, which is to ask you to get on a call and find out. Then you spend forty-five minutes explaining the situation out loud, they spend forty-five minutes taking notes, and at the end you have the same information you could have written down in twenty minutes, except now three firms have each consumed an hour of your week.
A good first email collapses that. It lets a firm reply with something specific: a rough range, a question that shows they understood, or an honest “this is not what we do.” That last answer is worth a great deal, and you will not get it from a firm that has not been told enough to know.
It also filters. A message with real detail gets read by an engineer at a small firm and by a salesperson at a large one, and the difference between those two replies tells you who you would be working with.
The six things
Everything useful fits under six headings. None of them requires you to know anything technical.
1. What you want to be different. Not the solution — the outcome. “Our three-person team spends most of Monday reconciling orders across two systems by hand, and I want that to stop.” That sentence is worth more than any amount of feature description, because a firm that knows the outcome can tell you when a smaller, cheaper thing would achieve it. If you lead with “we want to build a machine learning model,” you have already made the decision that the outside expert was supposed to help you make.
2. What exists today. Which systems hold the data, roughly how much of it there is, how it moves now, and what the manual workaround is. Names of products are fine and helpful. Volumes matter more than most people expect: two thousand documents a month and two million are different projects with different architectures and a tenfold difference in price.
3. The constraints. A date and why that date. A budget or a range. Anything that is non-negotiable — data that may not leave your network, a system nobody is allowed to modify, a platform decision already made at board level. Constraints are not bad news; they are the shape of the problem, and a firm that hears them early can design inside them instead of proposing something that dies in week three.
4. Who decides, and what the path looks like. Whether you can sign, or your CFO signs, or it goes to a committee that meets monthly. This changes nothing about the work and everything about how a firm plans its capacity. It is also the single most common reason a promising conversation goes quiet for two months.
5. What you would count as working. One or two sentences, ideally with a number in one of them. “Reconciliation takes under an hour a week instead of most of a day, and the team trusts it enough to stop keeping the spreadsheet.” The second half of that is often the harder half, and saying it out loud early is how you avoid buying something correct that nobody uses.
6. What you have already tried. The tool you bought that did not fit, the contractor who did three months and left, the internal attempt that stalled. This is not embarrassing information; it is the most efficient thing in the message. It tells a firm which explanations to skip and which failure mode to take seriously, and it is a strong signal that you will be a straightforward client.
Say the budget
This is the piece people resist, so it deserves the argument in full.
The fear is reasonable: name a number and the proposal comes back at exactly that number. Sometimes it does. But consider the alternative. The firm has to guess at scale, and guessing wrong is expensive in both directions. Guess high and you get a proposal for a platform when you wanted a tool, decide the firm does not listen, and move on — while a $50,000 version existed and was never described. Guess low and the proposal quietly omits the hard part, which arrives as a change order in month three.
A range is enough. “We have somewhere between $60,000 and $100,000 for this, and it has to be spent this fiscal year.” That single sentence lets a firm tell you honestly whether the thing you described is buildable for that, propose a smaller first version that is, or say plainly that it is not and explain what it would take. All three replies are useful. Silence buys you none of them.
The check on the obvious worry is easy: ask what a version at half the number would look like. Any firm worth hiring has an answer, because scoping down is most of what the job is. A firm whose proposal cannot be made smaller has not thought about your problem, only about their capacity.
What not to send first
| Instead of | Because | Do this |
|---|---|---|
| An NDA before any description | It adds days of legal review before anyone knows if there is a project, and the first paragraph rarely contains a secret | Describe the shape without the sensitive specifics; sign a mutual NDA before the detail |
| A 40-page formal RFP | Small firms often decline to respond, so you filter out the ones most likely to do the work themselves | Send the one-pager, then the long document to whoever engages |
| “Do you do AI?” | Every firm says yes, so the answer carries no information | Describe the task and the data, and let them tell you what it needs |
| A calendar link with no context | It asks the reader to spend an hour to learn what a paragraph would have told them | Context first; the meeting is more useful after both sides have read something |
| A request for the full capability deck | You will get marketing, and every firm's deck says the same words | Ask what they would do about your specific problem |
| A finished technical design | It hides the outcome behind a solution, and you lose the expertise you were buying | Send the design as an appendix, marked as your current thinking |
The NDA point is worth a moment because good people disagree about it. If the existence of the project is the secret, or the data is genuinely sensitive, then yes, get the mutual NDA in place first and accept the delay. Most of the time the secret is one layer down. You can say “a document processing workflow in the insurance space, high volume, tight turnaround” without giving away anything, and that is enough to start.
You are probably here because
- You emailed four firms and got four calendar links back
- The proposals you received were so different you cannot compare them
- You are not sure whether to say your budget, and everyone has an opinion
- The last engagement went sideways and you think it started badly
The six-things section is the whole method. The attachments section is what makes a reply specific instead of generic.
What most improves the reply you get — our read
Our judgment of what changes a reply, not a survey. The bottom row is the most requested and the least useful.
Attachments that change the answer
You do not need many. Two or three of these will move a reply from generic to specific.
A screenshot of the thing being done by hand. The spreadsheet, the queue, the screen someone stares at. One image explains more than four paragraphs, and it is the artifact engineers actually look at first.
A sample file with the real structure and fake values. Column names, types, a dozen rows, invented content. This is the highest-value attachment on the list and it takes ten minutes to produce. Real column names alone tell an experienced engineer whether your data is well kept, and a sample with three date formats in one column tells them exactly how much cleaning work is hiding in the estimate.
A one-page current-state sketch. Boxes for systems, arrows for how data moves, drawn badly. Photographed from a whiteboard is entirely fine. If nobody in your organization can draw it, that is a finding, and worth saying out loud in the email.
The actual error or the actual complaint. The support ticket text, the message the system throws, the sentence a customer wrote. Primary material beats summary every time.
Numbers. Rows, documents, users, requests per day, growth over the last year. Order of magnitude is enough. “About 40,000 invoices a month, growing maybe 20% a year” is a complete answer.
The shape, as an example
Illustrative — not a real client, and yours will differ. What matters is the density of fact per line.
Subject: Invoice matching — 40k/month, two systems, want a range
Hello — I run operations at a distribution company, about 90 people. Three of my team spend roughly a day a week matching supplier invoices against purchase orders. The invoices arrive as PDFs by email, the purchase orders live in our ERP, and the matching is done by eye in a spreadsheet. About 40,000 invoices a year, growing.
I want most of that matching to happen automatically, with a human reviewing only the ones that do not line up. Success for me is the team spending under two hours a week on it and trusting the result enough to drop the spreadsheet.
Constraints: our ERP vendor charges for API access and I do not yet know what they will allow. Budget is $50,000 to $90,000. I can sign up to $75,000; above that my CFO approves, which adds about three weeks. I would like something running before our year end in March.
We tried an off-the-shelf capture tool last year. It read the PDFs adequately and could not match against our purchase orders, so it was abandoned.
Attached: a screenshot of the spreadsheet, one sample invoice with the numbers changed, and the ERP's API documentation page. Happy to answer questions by email — is this something you do, and roughly what would it cost?
Under three hundred words. Every one of the six things is present. A firm can answer that in a day with something specific, and the reply you get is a genuine sample of how they think.
How to read the reply
The response is your first real data about a firm, and it is free. Here is what we would weigh.
| Signal | What it usually means |
|---|---|
| They ask about failure — what happens when the match is wrong, who catches it | They have shipped things. The failure path is where real systems are won or lost |
| They say no to part of it | A very good sign. Firms that agree with everything have not read carefully or intend to bill the difference |
| They propose something smaller first | They are optimizing for the project succeeding rather than for the size of the first invoice |
| They give a range with assumptions attached | They estimate honestly. A single confident number this early is a sales artifact |
| They name the risk you were quietly worried about | They understood the actual problem, not the description of it |
| A deck and a calendar link, no content | You are in a sales process, and the engineer has not read your email |
| A firm price within an hour | Either a template or a rate card. Ask what happens if the ERP refuses API access |
| Enthusiasm about the technology rather than about your outcome | Common, and survivable, but expect to steer |
On timing: one to two business days for a first human reply is normal for a small firm. Three to ten business days for something scoped, if they are interested and busy. Silence past a week usually means capacity rather than disinterest, and a one-line nudge is entirely welcome — nobody is offended by it.
What happens on the other side
Small firms triage. The questions asked internally, in order, are roughly: is this the kind of work we do, is the timeline compatible with what we already committed to, is the money in a range where we can do it properly, and is this someone we can work with. An email that answers those four questions gets a real reply. An email that answers none of them gets whatever the least-busy person can produce in five minutes.
It also helps to know that the honest answer is sometimes “not us.” A firm with the wrong specialty, or with no room until the spring, is doing you a favor by saying so quickly. You are more likely to get that favor when the email made it obvious, and less likely when the only way to find out was a discovery call that has its own momentum.
Mistakes we see in first emails
- Leading with the solution — naming the technology and hiding the outcome you actually want
- No numbers anywhere — no volumes, no users, no dates, so any estimate is invented
- The same message to twelve firms, obvious from the phrasing, which lowers everyone's effort in reply
- Hiding the deadline until after the proposal arrives, when it would have changed the design
- Describing a system rather than a problem, so the firm's experience never gets applied
- Asking for references and a deck before saying what the work is
- Sending it to a generic contact form when a named engineer is one click away
- Requiring an NDA to describe a problem that could be described in a sentence without one
Before you hit send
- The outcome you want is in the first three sentences, in plain language
- The systems that hold the data are named
- There is at least one volume number and one date
- A budget or a range appears somewhere
- Who signs, and how long that takes, is stated
- You wrote one sentence about what “working” would look like
- You said what you already tried and why it stopped
- One screenshot and one sample file are attached
- It fits on one screen
- You asked a direct question that can be answered in writing
Bottom line
Twenty minutes spent writing one page will save you several hours of calls and will get you better answers from better people. Say the outcome, not the technology. Name the systems and the volumes. Give a date, a budget range and the approval path. Say what you already tried. Attach a screenshot and a fake-value sample. Then judge the replies by whether they asked about failure, said no to something, or made the project smaller — those three are the ones worth taking further.
Frequently asked questions
Yes, as a range. Without it the firm guesses at scale and half the time guesses wrong in a way that wastes both of you. The protection against a proposal padded to fill the number is to ask what a version at half the budget would look like — a firm that cannot answer that has not thought about your problem, and a firm that answers it well has just shown you how it thinks.
Usually not, because you can describe the shape of a problem without the sensitive part. Insisting on one first adds days of legal review before anyone knows whether there is a project. Where the data itself or the existence of the effort is confidential, put a short mutual NDA in place before the detail, and accept that it costs you a few days.
Three or four is enough to compare and few enough to give each a real message. More than that and the enquiries become generic, which produces generic replies, and you end up comparing sales writing rather than thinking. Send them separately rather than in one addressed group; the reply you get to a personal message is a different quality of reply.
Then say that, and describe the situation instead of a solution. “Here is what my team does today, here is what it costs us, I am not sure what the right answer is” is a perfectly good first email and often a better one. What does not work is guessing at a technical solution to sound prepared, because the firm will then price your guess rather than your problem.
Four or five business days, then one short line. Small firms genuinely miss messages during a busy delivery week, and a nudge is welcome rather than pushy. If a second follow-up gets nothing, take it as a capacity answer and move on without reading anything into it — a firm that is fully booked is not a firm that is unimpressed.