What to send a consultant before the first call
The first-call checklist is four things to send a consultant before you speak: the problem in a few sentences, how it works today, your tools and who controls access, and who decides and what is sensitive. None of it needs to be polished. The call can then go on what should change, and the scope and quote are based on the real process.
On this page
Key takeaways
- Before a first call, send a consultant four things: the problem, how it works today, your tools and who controls access, and who decides and what is sensitive.
- None of it needs to be polished, because a whiteboard photo, a few screenshots or a quick export all work.
- A consultant who has read it can spend the call on what should change, and can scope and quote from the real process instead of a description.
4 things Worth sending, none of them polished.
3 types Of project, each with its own checklist.
2 stages Before the first call, and before the work starts.
A good part of most first calls I have with new clients goes on working out how things run today: which tools are involved, who does what, and where the data lives. That's a completely normal part of starting a project. But when a client sends a few things ahead of time, I can read them before we speak, come to the call with better questions, and we get to spend most of our time on what should change.
It also tends to make the scope and the quote more accurate, because I'm working from the real process and the real data, and it's often what decides how quickly a project can start. The tool I use for this is the first-call checklist: the four things I find most useful to see, and a checklist for each of the three types of work I do.
Why send anything before the call?
Both routes get you to a project. The second one gets you there with fewer follow-up emails and fewer surprises once the build has started.
Nothing sent ahead
- The process gets explained on the call
- Files and access get chased after
- The scope is based on a description
- Surprises turn up during the build
A few things sent ahead Fewer surprises
- I read it before we speak
- The call goes on what should change
- The scope is based on the real process
- Work starts once access is set up
The difference is when the gaps show up. Without anything sent ahead, they show up once the build has started. With it, they show up while the scope is still being written.
It doesn't need to be polished
Send what you have, in whatever shape it's in.
- Rough is fine. A whiteboard photo, a few screenshots or a quick export all work.
- Gaps are useful. If something doesn't exist yet, it often becomes part of the project.
- Sensitive data can wait. Tell me it exists, and send it once we've agreed how it's handled.
The four things worth sending
These are the four things I find most useful to see before a first call. Each one is a few lines, and the last three come with the reason I ask for it.
The problem, in a few sentences
What's happening, who it affects, and what you'd like to be true once it's fixed.
For example "Our team spends about two days a month building the board report by hand, and we'd like it to update itself."
How it works today
A rough list of the steps, who does each one and in which tool, plus a few real examples like a small export or screenshots.
Why I ask. Real processes and real data show the handovers and exceptions that a description tends to leave out.
Your tools, and who controls access
The tools involved, the plan you're on, and who can grant access once we agree to go ahead.
Why I ask. Access often takes longer to arrange than expected, especially when IT or a vendor has to approve it.
Who decides, and what's sensitive
Who signs off, any fixed dates, and whether the work involves personal or financial data or needs an NDA first.
Why I ask. A fixed date or sensitive data changes how a project is scoped, and sometimes means planning more up front.
Checklists by type of project
Here's the checklist I'd send for each of the three types of work I do. Each one is split into what helps before the first call and what I'll need once we agree to go ahead. Tick off what you can, and leave the rest for us to work through together.
Your ticks are saved in this browser only. Nothing is sent anywhere.
Business systems and automation
Business systems and automation: Before the first call
Six things that help before we speakBusiness systems and automation: Before the build starts
Four things I'll need once we agree to go aheadCX, research and analytics
CX, research and analytics: Before the first call
Six things that help before we speakCX, research and analytics: Before the build starts
Four things I'll need once we agree to go aheadBusiness strategy and operations
Business strategy and operations: Before the first call
Six things that help before we speakBusiness strategy and operations: Before the work starts
Four things I'll need once we agree to go aheadWhat happens after you send it?
I read it before we speak and come to the call with better questions. The call can then go on what should change instead of on how things run today.
- Before the call. I read what you sent and come with better questions.
- On the call. We spend most of our time on what should change.
- When it's scoped. The scope and the quote are based on the real process and the real data, which makes them more accurate.
- Once we go ahead. Work starts when access is set up, which is why the tools and who controls access are on the list.
If something is missing
You do not need to fill every gap before you write. If something doesn't exist yet, say so. It often becomes part of the project, and the rest we can work through together.
From the work
Two projects on this site started the way this checklist does, from the real process and the real numbers instead of a description.
For a US research organisation whose survey programme had outgrown its tools, I mapped the full survey process first, including how towns were assigned and how data flowed from respondent to analyst, and then built on that.
Read the case study Case study Preventing $1.7M in profit margin erosionFor a professional services organisation, the problem came with a number: a yearly $3.5M gap between estimated and actual project margins, which I traced to its root causes across 10,000+ yearly projects.
Read the case studyQuestions people ask
Do I need to send everything on the list?
No. Tick off what you can and leave the rest for us to work through together. Send what you have, in whatever shape it is in.
What if we have not documented the process?
Rough is fine. A whiteboard photo, a few screenshots or a quick export all work, and so does a rough list of the steps, who does each one and in which tool. If something does not exist yet, it often becomes part of the project.
Do I need an NDA before sending anything?
Not for the first things on the list. If the work involves personal or financial data, or you need an NDA first, say so in your message. Tell me the sensitive data exists, and send it once we have agreed how it is handled.
Why does access matter so early?
Access often takes longer to arrange than expected, especially when IT or a vendor has to approve it. Knowing which tools are involved, which plan you are on and who can grant access means work can start once access is set up, instead of waiting for it.
What do you do with it before the call?
I read it before we speak and come to the call with better questions. That way most of our time goes on what should change, instead of on working out how things run today.
More resources
A note from me
Have a project coming up?
The more I can read before a first call, the more of that call we can spend on what should change. If you have a project coming up and would like the checklist that fits it, send me a message.