AI Adoption GuideConsultingKickoff
Stakeholder Onboarding Brief Synthesizer
RAG over client filings, news, and prior meeting notes produces role-specific onboarding briefs for each incoming consultant.
Consulting processSellScopeStaffKickoffAnalyzeRecommendDeliverClose
By Don, DoneThat’s AI coach · updated
Joiners get a different brief from the pitch team
After the SOW is signed, each incoming consultant needs a pack that matches their role, not a recycled pitch dump. The job is speed: they should arrive already knowing the workstream, the people they will meet, and what this firm already tried with this client.
The pre-pitch client context brief is for the pitch team, before the win. This synthesizer runs after the win, for joiners, with role-specific packs and tighter confidentiality. Fee tables, discount history, partner commentary on the client's CFO, and notes about people on your own team do not belong in a file the whole engagement can open.
An analyst joining in week two otherwise learns the account by interrupting people who are already in client meetings. Retrieval over filings, news, prior meeting notes, and closed-work records is how you stop that scavenger hunt. Tools in the Glean, Hebbia, AlphaSense, PitchBook, Notion, and McKinsey Lilli class are how firms already search internal work, filings, news, and the project workspace. Treat them as a retrieval class, not a ranked shortlist. None of them decide what is safe to put in an analyst pack. You do.
The brief is homework. It is not a substitute for the conversation with the workstream lead. If you treat a generated document as onboarding, joiners show up fluent in last year's 10-K and still lost on this week's work.
Build the analyst pack first
Start with the analyst role. That is where the context gap is largest and the material is least sensitive. Do not begin with a partner pack and then "redact down." Redaction fails. People forward the original.
Analyst pack
Write for the person who will sit in the data room and on the first workshops:
- Signed scope in plain language: what we were hired to do, what is out of scope, which workstream they own.
- First two weeks of work: tasks, artifacts, who they report to on the team.
- Named client stakeholders they will actually meet, with role, last meeting date, and last known stance. Not the entire org chart.
- How the client describes the problem, taken from sale and kickoff notes, not from a homepage.
- Access: data rooms, tools, environments. If something is still blocked, say so and point to the pre-kickoff readiness gap detector rather than pretending day one is clean.
- Prior work this firm did for this client, at the level an analyst needs so they do not re-propose something already rejected.
Keep company background to a short "what changed since we last sat with them" block. A generic company Wikipedia dump is the usual failure: founding story, segment mix, and a leadership list the joiner could have found quickly. Analysts skip that document, including the parts that were actually useful.
Partner pack
Generate this later, behind a tighter ACL:
- The same delivery context the analysts have.
- Commercial: fee, discount, change-order posture, who signed, payment terms.
- Political map: who is sponsoring, who is skeptical, which internal fights the partner already knows about.
- Staffing: why this mix, who is stretched, who must not be pulled onto something else.
Never paste commercial or HR detail into the shared pack and hope people know not to discuss it with the client. If the retrieval index can see the commercial file, constrain sources by role or the model will put margin commentary into the analyst's day-one page.
Who should join is a skills-to-project matching engine problem. This synthesizer writes packs for people already named on the staffing file.
Prior engagement history is the part they cannot search for
Public filings and news are the easy layer. An analyst can pull those. Prior engagement history is the rare layer: other practices' work on this account, hypotheses you already tested, recommendations the client already declined, data you already collected.
Include that history on purpose. Put it near the top of the analyst pack, not in an appendix. The project knowledge base ingestion agent is how closed work becomes retrievable. If those records were never classified and tagged, the synthesizer will fill the hole with 10-K language and you will have rebuilt the Wikipedia dump.
Retrieval over "similar engagements" is how you leak another client's name. A model that has seen a warehouse program at Vesper Freight will drop "Vesper" into a Helios Transit brief because the operations look alike. That is a confidentiality failure, not a citation. Strip other-client identifiers before publish. You can say "a prior network-scheduling diagnostic in public transit" if the method is relevant. You cannot name Vesper, and you cannot include Vesper's numbers.
Scan every pack for:
- Other client names, logos, file paths, and Slack channel names.
- Fee, margin, discount, and partner compensation.
- Performance notes, utilization complaints, and why someone was not staffed.
- Anything the client has not seen that would embarrass them if it landed in a forwarded PDF.
The engagement manager reads the analyst pack once before it is shared. Retrieval does not get a free pass because the source was internal.
Illustrative example: Helios Transit diagnostic, week of 14 April
This is a worked example with made-up names, written to show the cuts, not a case study with results.
Dana is the engagement manager on a signed ops diagnostic at Helios Transit. The partner has been on the account through the sale. Two managers start on day one. Three analysts join on 14 April. Jules is new to transit and new to this client.
Dana's first instinct is to drop the pitch brief into the project workspace. That file opens with Helios's founding year and ridership mix, then a news roundup, then an appendix with the fee, a line that the CFO fought the last bid, and a comparison to "the Vesper Freight network program." Every joiner can open it. That is a Wikipedia dump, an other-client leak, and a commercial spray in one document. It also lets Dana skip introducing Jules to the workstream lead, because the brief is already in Notion.
What she should ship instead:
Jules's analyst pack leads with the signed diagnostic questions, his workstream (garage operations, weeks 1-2: current roster process, first site visits), the two Helios managers he will sit with, and the last workshop notes on those questions. It includes the scheduling study another practice ran for Helios two years ago, and the explicit note that the board declined the recommended rostering change: do not re-propose it in week one. Access that is still waiting on Helios IT is listed as open, not as done. Company background is one paragraph on what changed since that earlier study.
The partner pack, in a restricted folder, holds the fee, the discount that closed the deal, the CFO note, and the staffing mix. The kickoff deck auto-assembler pulls client context from the delivery-safe layer, not from the partner folder.
Jules still has a conversation with the garage workstream lead on day one. The pack is so that conversation is about judgment (what "declined" means in this building) rather than "what is this project."
The pack is homework, not onboarding
Three failure modes show up as soon as this is convenient.
Generic company dump. If page one could have been copied from a public profile, the rest will not be read. Lead with this engagement, this workstream, this week's work.
Other-client names. Similar-work retrieval is useful only after identifiers are stripped. A human scan is part of publish. If you cannot describe the prior work without naming the other client, leave it out of the analyst pack.
Brief as substitute for the workstream-lead conversation. The synthesizer makes joiners faster to that conversation. It does not replace it. Require the meeting. Ask joiners after two weeks what they still had to ask about, and put those answers into the next analyst pack. Refresh the pack when stakeholders or decisions change. A brief frozen at kickoff is already wrong by week three.
Success is operational, not a claimed time saving. Joiners stop asking what we were hired to do. The commercial file never appears in the shared workspace. Other clients are not named. The workstream lead still talks to every joiner.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first