What to send a consultant before the first call (and what to leave out)

A few weeks ago I was fifteen minutes into what should have been a scoping call when I realized we were still untangling which version of the org chart was current. The client had sent six documents the night before, each one confidently titled "FINAL," and none of them agreeing on who owned the budget. We spent the first third of our hour on archaeology. That kind of call is recoverable — most first conversations are — but it sets a particular tone, and that tone tends to cost more than people expect, in time, in goodwill, and eventually in fees. What follows is a frank account of what actually helps before a first consulting engagement begins, drawn from years of those calls, the good ones and the ones that started in the weeds. The goal is not to hand you a checklist, but to give you a clear enough mental model that you can make good judgment calls on your own, whatever your situation looks like.

The night-before temptation ¶

There is a recognizable impulse that strikes most clients somewhere between booking the call and going to bed the night before it: the urge to send everything. The last three annual reports. The strategic plan drafted in 2019 that never quite launched. The thread of internal emails that tells the 'real story.' The deck from the all-hands in April. Each document feels relevant in isolation, and the act of sending feels productive — like a kind of generosity, a demonstration of good faith. In practice, it functions more like noise.

What a consultant can usefully absorb in the hours before an introductory call is far less than most clients imagine. We are not yet oriented to your organization's particular vocabulary, its internal shorthand, the names that carry weight. A 60-slide deck read cold, without that orientation, yields maybe four or five genuinely useful data points. The rest we will reread after the call, once we have the frame. Sending it beforehand does not accelerate that process; it just shifts where the processing happens, from a conversation that could have been generative into a solo reading session that produces tentative, unanchored notes.

What the problem statement is actually for ¶

The single most useful thing you can send before a first call is a short, plain-language description of the problem as you currently understand it. Not as you wish it were framed. Not as it was framed in the board memo. As you, the person picking up the phone, actually see it from where you sit. Two or three paragraphs is plenty. The discipline of writing it down — without access to a slide template, without a colleague to defer to — tends to surface something important: whether you have a clear problem at all, or whether what you have is a cluster of symptoms you have not yet organized into a diagnosis.

A good problem statement tells me three things before the call begins. It tells me what is happening that should not be, or what is not happening that should be. It tells me roughly when this became visible as a problem, because timing often carries information about cause. And it tells me who is affected and in what way, because the shape of the impact usually points toward where the leverage is. None of that requires formal language or strategic framing. It just requires honesty about what you are seeing.

The framing does not need to be correct. In fact, one of the most useful things a first call can do is help a client reframe a problem they have been holding in a way that makes it harder to solve. If you have already written down your current frame clearly, we can examine it together. If you have sent me a glossy problem statement polished by a communications team, we have to spend time getting back underneath it to the actual experience.

The discipline of writing it down without a slide template tends to surface something important: whether you have a clear problem at all.

The documents worth sending ¶

With the problem statement written, there is a short category of supporting material that genuinely earns its place in a pre-call email. The criterion is simple: does this document change how I would approach the first conversation, or does it just add texture I can gather during the call itself? Texture can wait. Context that would change my line of questioning cannot.

An organization chart — current, one page if possible — belongs in that first email, not because consultants are obsessed with hierarchy, but because knowing who holds the decision rights on a problem tells me immediately whether the right people are in the room, or whether we are going to spend the engagement working around someone who was never consulted. A single page of financial context belongs there too, not a full set of accounts, but enough to know the order of magnitude: are we talking about a team of eight or a division of four hundred, a budget question measured in thousands or in millions. If there is a specific external constraint driving urgency — a regulatory deadline, a tender closing date, a board presentation already scheduled — that belongs in the email, because it sets the clock.

Everything else can come later. The internal reports, the customer feedback, the prior consultant's deck from three years ago: I will want to see all of it eventually, but 'eventually' is not 'tonight.' Send what changes the shape of the first conversation. Hold back what adds detail to a conversation we have not had yet.

What to leave out entirely ¶

There is a category of material that actively complicates a first call rather than supporting it, and the common thread running through it is premature conclusion. A document that has already decided what the solution is — a business case written to justify a decision already made internally, a proposal drafted by a vendor who recommended the engagement, a strategic plan built on assumptions the organization no longer quite believes but has not formally revisited — lands differently than it appears to. It does not give me useful background. It gives me a conclusion I have to either endorse or spend time carefully walking back, and neither option is a good use of a first conversation.

Internal politics documentation belongs in this category too. The email chain demonstrating that a particular colleague has been obstructing progress, the annotated org chart showing who 'really' has influence, the forwarded message that contextualizes someone's behavior: I understand why clients send these things, and I do not doubt that they represent real experiences. But receiving a one-sided political account before I have met any of the parties involved skews my perception in ways that are genuinely difficult to correct later. That context is best shared in a conversation, where I can ask questions, than in documents that land as settled fact.

How to frame the ask ¶

Beyond the problem statement and the short stack of supporting documents, the most useful thing in a pre-call email is a sentence or two about what you are hoping to walk away from the first conversation knowing. Not what you hope the engagement will eventually produce — that is a much larger question — but what a good first hour looks like from your seat. Do you want to leave with a clearer sense of whether this problem is within scope for an external engagement at all? Do you want to pressure-test a particular hypothesis you have been carrying? Do you want to understand what a realistic timeline looks like, given your constraints? These are different conversations, and flagging which one you are hoping to have means we can prepare accordingly.

This kind of explicit framing feels slightly awkward to write, because it can seem like you are managing the consultant rather than collaborating with one. In practice, it is the opposite. It signals that you have thought about the conversation as a conversation, with a purpose, rather than as an open-ended brief where anything goes. Consultants who are worth their day rate appreciate that signal enormously. It means the first call is likely to produce something, rather than functioning as an extended introduction.

A compact pre-call checklist ¶

To make this practical: before you send anything, run through the short sequence below. It takes perhaps twenty minutes, and it tends to produce a pre-call email that is one screen long rather than six attachments deep. The test for each item is the same one used throughout this piece — does it change the shape of the first conversation, or is it texture that can wait?

• Write a 2-3 paragraph problem statement in plain language, as you currently see it, before opening any existing documents.
• Attach a current org chart, one page, with decision-makers identified.
• Include one paragraph of financial or operational scale context — order of magnitude only.
• Note any hard external deadlines or constraints driving the urgency.
• Write one or two sentences about what a useful first conversation looks like from your side.
• Review your attachments: if a document argues for a conclusion rather than describing a situation, hold it back until after the first call.

A first consulting call is not a presentation and it is not an interview. It is, at its best, the first real thinking session of the engagement — the moment when someone outside your organization hears the problem fresh and begins asking the questions you have stopped asking because they seem obvious from the inside. The preparation described here is designed to get you to that moment faster, with less of the first hour spent on logistics and more of it spent on the actual work. Send the problem. Hold the politics. Name what you need from the hour. The rest follows from there.