Bring the raw material, not a perfect brief
You do not need a polished strategy document. Bring the material that shows how your audience thinks: high-performing posts, recurring questions, customer language, previous offers, and objections you hear repeatedly. A good builder can turn that material into structure; they should not have to manufacture it.
Include what did not work as well. A page that received attention but no qualified replies can be more informative than a post that went viral. The goal is not to prove that every past decision was correct. It is to give the operator enough context to make a sharper next decision.
- Your current offer, price or pricing logic, delivery format, and who should not buy it.
- A short description of the audience’s urgent problem in their own words.
- Links to your strongest content and examples of your normal voice.
- Existing pages, email sequences, checkout links, analytics, and brand assets.
Decide the boundaries before the build
A funnel project becomes vague when “build the funnel” is treated as a deliverable. Decide whether the first scope includes strategy, copy, design, implementation, integrations, QA, launch support, and optimization. Each is a different kind of work and may require a different specialist.
Access is another boundary. List what an operator may view, edit, or publish. Use separate accounts or permissions where possible, and never put passwords into a project brief. The creator should remain able to revoke access and preserve ownership of the finished assets.
- Name the pages, messages, integrations, and handoff materials included in version one.
- Define who approves copy, what “ready to launch” means, and how revisions work.
- State the launch date as a target, not a substitute for acceptance criteria.
- Identify data, customer stories, or claims that require proof before publication.
Use the first call to test fit
The first conversation is not only for hearing what the operator can build. It is also for seeing how they think. Ask what they would clarify, what they would leave out of version one, and where they see risk. A strong operator should be comfortable narrowing the brief instead of adding complexity.
Source-E’s process is designed around this kind of fit: creators describe the audience and need, operators show relevant proof of work, and a written Statement of Work makes the proposed build concrete before work begins.
Before you move forward
- Offer, audience, voice examples, and existing assets are in one reviewable place.
- The first version has a named boundary and an approval owner.
- Tool access can be granted without sharing personal passwords.
- I can explain what success would look like without promising a specific result.