By the Templateez Team · Licensed Attorney · June 2026

Freelancer & Gig Worker Intake Forms: What to Capture at Client Onboarding

A freelancer who starts work based on a Slack message and a handshake is going to discover, three weeks in, that the client expected unlimited revisions, owns the source files outright, and considers the invoice "a suggestion." The project that seemed straightforward at the kickoff call becomes a dispute about scope, a chase for payment, and a lesson about why onboarding documentation matters.

Whether you are a graphic designer, a software developer, a copywriter, a video editor, or a virtual assistant, the problems are the same. Scope is undefined. Payment terms are vague. IP ownership is never discussed. Revisions spiral because nobody established what a revision actually is. A proper freelancer intake form captures everything you need before writing a line of code, designing a single mockup, or drafting a first paragraph. Here is what that form should include — across creative, technical, and service-based gig work.

Client information: know who you are working with

This seems obvious, but freelancers routinely start projects without knowing who approves the final deliverable, who handles payment, or what timezone the client operates in. That last one matters more than most people think — a freelancer in Portland working with a client in London who expects real-time Slack responses during GMT business hours has a scheduling conflict that should surface at intake, not two weeks into the project.

Your intake should capture:

• Client name and company — the individual you are dealing with and the organization they represent. These are often different people in terms of decision-making authority.
• Industry — knowing whether the client is in fintech, healthcare, fashion, or SaaS changes how you approach the work, what compliance considerations apply, and what kind of deliverables they are accustomed to receiving.
• Company size — a five-person startup and a 2,000-person enterprise have fundamentally different approval workflows, brand requirements, and payment timelines.
• Primary contact — the person who approves work, gives feedback, and makes decisions. This is not always the person who hired you. Capture separately: who approves the work, who gives day-to-day feedback, and who pays. These are sometimes three different people.
• Billing contact — if the person managing the project is not the person who processes invoices, you need both contacts. Sending an invoice to your project contact who then has to "forward it to accounting" adds two weeks to your payment cycle.
• Timezone — critical for remote work. Establish this upfront so both sides know when to expect responses, when meetings can be scheduled, and what "end of day" means.
• Communication preferences — email, Slack, Microsoft Teams, Asana, Trello, Discord, text. Every client has a preferred channel, and many have a preferred channel that is different from the one they told you about. Capture the primary channel and a backup. If the client uses a project management tool, you need to know whether you are expected to live in it or just check it periodically.

Project scope: define the work before you do it

Scope is where freelance engagements succeed or fail. A client who says "build me a website" has not described a project — they have described a category of work that could take forty hours or four hundred. Your intake form is where you convert a vague request into a defined engagement.

• Project type — is this a one-off deliverable, an ongoing retainer, or per-piece work? A one-off logo design and a monthly retainer for social media content are structured completely differently in terms of pricing, timelines, and deliverable expectations.
• Project description — in the client's own words. Let them describe what they need before you translate it into a scope of work. Their language tells you what they actually care about, which is often different from the technical specification.
• Deliverables — what exactly will you hand over? A logo designer might deliver the final mark in SVG, PNG, and EPS formats plus a brand usage guide. A web developer might deliver a deployed site plus the source repository. A copywriter might deliver a Google Doc with ten blog posts. Spell it out.
• File formats — PSD, AI, Figma, PDF, DOCX, MP4, WAV, code repository. Clients often assume they will receive files in a format they can edit. If you are delivering a Figma file and they do not have Figma, that is a problem that should surface now.
• Revision rounds — how many are included in the project price, and what counts as a revision versus new scope? "Can you make the logo bigger" is a revision. "Actually, we decided we want a completely different concept" is new scope. Define the line.
• Timeline — deadline, milestones, and whether the deadline is flexible or hard. A conference keynote deck due the morning of the event is a hard deadline. A website redesign that would be "nice to have by Q3" is flexible. Your pricing and stress level should reflect which one you are dealing with.
• Priority — is this the client's only active project with you, or one of several? If you are managing three concurrent workstreams for the same client, the intake for each one should acknowledge the others.
• Dependencies — does the client need to provide assets, content, access credentials, or approvals before you can start? A web developer waiting on copy. A designer waiting on photography. A video editor waiting on raw footage. Document every dependency at intake so delays are attributable and timelines can adjust accordingly.

Creative brief: for designers, writers, and content creators

If your work involves any creative judgment — visual design, copywriting, video production, illustration, branding — the creative brief is the most important section of your intake. A client who says "make it look modern" has communicated nothing actionable. A creative brief turns subjective preferences into concrete direction.

• Brand guidelines — does the client have a style guide, brand book, or tone-of-voice document? If yes, get it before you start. If no, your intake should capture enough information to establish a working creative direction.
• Target audience — who is the end user of this work? A LinkedIn carousel targeting CFOs and a TikTok video targeting college students require fundamentally different creative approaches, even if the underlying product is the same.
• Examples they like and do not like — ask for both. "We love the Stripe website" tells you something. "We do not want anything that looks like our competitor's rebrand" tells you something equally important. Negative examples prevent wasted rounds.
• Color palette, fonts, and visual direction — specific hex codes if they have them, general preferences if they do not. "Warm tones, clean sans-serif, lots of white space" is enough to start. "Make it pop" is not.
• Existing brand assets — logos, photography, templates, icon libraries. What do you have to work with? Starting from scratch and building on existing assets are different engagements with different timelines.
• Competitors — who should the work not look like? This is different from examples they dislike. Competitors are companies in the same space whose visual identity your client needs to differentiate from.
• Approval process — who signs off on creative work, and how many rounds of review happen before final approval? A solo founder who approves on the spot and a marketing team with three layers of sign-off create very different project dynamics.

If you are doing graphic design and branding work specifically, see our dedicated guide for the full breakdown of what a design-focused intake should capture.

Technical requirements: for developers, engineers, and IT freelancers

Technical freelancers have an additional layer of intake that does not apply to creative work — the client's existing technical environment. You are not working on a blank canvas. You are working inside someone else's system, and you need to understand that system before you touch it.

• Tech stack — languages, frameworks, libraries, CMS, hosting provider. A React project and a WordPress project are different engagements. A client who says "we need a developer" without specifying the stack is a client who does not yet know what they need.
• Repository access — GitHub, GitLab, Bitbucket. Will the client add you to their existing repo, or will you create a new one and transfer ownership at the end? Clarify branching strategy, PR review process, and merge permissions.
• Development environment — staging, production, local setup. Do they have a staging environment? Will you deploy to staging for review before production? Who has production access?
• Testing requirements — unit tests, QA process, browser compatibility, accessibility standards. Some clients expect 90% test coverage. Others have never heard of a unit test. Know which one you are working with so your estimate reflects the actual workload.
• Documentation — is the freelancer expected to document their work? A developer who ships code without documentation and a developer who ships code with inline comments, a README, and an architecture diagram are quoting different amounts of work.
• Deployment — who deploys? Is there a CI/CD pipeline, or is deployment manual? If you are expected to handle deployment, you need access to the hosting environment, DNS records, and any relevant credentials.
• Existing codebase — is this greenfield (building from scratch) or are you working within existing code? If existing, how old is it, how well-maintained, and is there technical debt you should know about? An honest answer here prevents the most common freelance developer conflict: "This is taking longer than you estimated." Yes, because the existing codebase was held together with duct tape and nobody mentioned that during onboarding.

For web design projects that blend creative and technical requirements, the intake needs to cover both the visual direction and the development environment.

Access and tools: credentials, platforms, and logistics

Every freelance engagement requires access to something — a design file, a codebase, a content calendar, a social media account, a CMS. The intake is where you document what access you need and how it will be provided.

• Credentials — capture what access is needed, but never accept plaintext passwords in a form field. Note that credentials should be shared via a password manager (1Password, LastPass, Bitwarden) or the client's IT provisioning process. A client who emails you a Google Sheet with all their passwords is a client who needs to hear about password managers before you proceed.
• Project management tool — does the client use one (Asana, Trello, Monday, Jira, ClickUp, Notion), or does the freelancer bring their own? If the client has an existing workflow, you are joining it. If they do not, this is an opportunity to establish one — but agree on it at intake, not three weeks in when tasks are being tracked across email threads and Slack messages.
• File sharing — Google Drive, Dropbox, WeTransfer, OneDrive. Where do files live? Where do you upload deliverables? Having a shared folder set up before work begins eliminates the "where did you send that file" conversation.
• Communication platform — where does day-to-day communication happen? This is different from the formal communication preference captured earlier. A client might prefer email for approvals but Slack for quick questions. Establish both channels.
• Time tracking — is it required, and if so, what tool? Toggl, Harvest, Clockify, or the client's internal system? For hourly engagements, time tracking is non-negotiable. For project-based work, the client may still want visibility into how hours are allocated.
• Invoicing — does the client have a vendor portal or accounts payable system you need to submit through? Large companies often require vendors to register in a procurement system before the first invoice can be processed. Discover this at intake, not when your first invoice bounces back with "please submit through Coupa."

Pricing and payment: the section that protects your income

This is where most freelancers get hurt. The work gets done. The invoice gets sent. The payment does not arrive. Or it arrives sixty days later, or the client disputes the amount because the agreed rate was never documented. Your intake form should lock down every financial detail before work begins.

• Rate structure — hourly, project-based, per-word, per-piece, day rate, or retainer. Each has different implications for scope management. Hourly rates protect the freelancer from scope creep but make clients anxious about open-ended costs. Project rates protect the client's budget but expose the freelancer to underestimation.
• Rate amount — the actual number. In writing. On the intake form. Not "we discussed it on the call."
• Estimate for this project — estimated hours and total cost. Even for project-based pricing, documenting the estimated hours gives both sides a reference point when scope discussions arise later.
• Deposit — standard practice for project-based work. Typical deposits range from 25% to 50% of the project total, due before work begins. A client who refuses to pay a deposit is telling you something important about how they value the engagement.
• Payment terms — net 15, net 30, on delivery, or milestone-based. Milestone-based payment is the safest structure for larger projects: 30% upfront, 30% at midpoint review, 40% on final delivery. It aligns payment with progress and limits exposure for both sides.
• Payment method — bank transfer (ACH or wire), PayPal, Wise, Venmo, check. International clients may need Wise or PayPal to avoid wire transfer fees. Domestic clients who insist on paying by check are adding five to ten business days to your payment cycle.
• Late payment terms — what happens when payment is overdue? A standard late fee (1.5% per month is common) and a work-stoppage clause (work pauses after 15 days overdue) should be documented at intake. Clients who know there are consequences for late payment tend to pay on time.
• Kill fee — if the client cancels the project mid-stream, what do they owe? A kill fee typically covers work completed to date plus a percentage of the remaining contract value. Without one, a client can cancel after you have blocked four weeks of your calendar and owe you nothing beyond the deposit.

Legal and IP: the section most freelancers skip

This is the section that separates professional freelancers from people who do freelance work. IP ownership, usage rights, and portfolio permissions are not edge cases — they are the core terms of every creative and technical engagement. Ignoring them does not make them go away. It just means you discover the disagreement when it is too late to negotiate.

• Contract — does the client have a standard contractor agreement, or does the freelancer provide one? Someone needs to provide one. Working without a contract is working without protection.
• IP ownership — work-for-hire versus license. This is the single most important clause in any freelance agreement. Under work-for-hire, the client owns everything you create — the final deliverable, the source files, the rough drafts, everything. Under a license model, you retain ownership and grant the client specific usage rights. The default under U.S. copyright law for independent contractors (not employees) is that the creator retains ownership unless a written work-for-hire agreement exists. Most clients assume they own everything. Most freelancers assume they retain rights. Document the actual agreement.
• Usage rights — where can the client use the work, and for how long? A logo design used on a business card is different from the same logo used in a national television campaign. Define the scope of permitted use: media types, geographic regions, duration, exclusivity.
• Portfolio rights — can the freelancer show the work in their portfolio, on their website, or on social media? Some clients — especially those with NDAs or in stealth mode — prohibit this. If you cannot show the work, that affects the project's value to your career, and your pricing should reflect it.
• NDA — is one required? If so, is it mutual or one-way? Most client NDAs are one-way (the freelancer is bound, the client is not), which is standard for most engagements but worth noting.
• Non-compete — be cautious about signing these. A non-compete that prevents you from working with any company in the client's industry for twelve months after the engagement ends could eliminate a significant portion of your potential client base. Flag non-competes at intake and review them carefully.
• Liability — a limitation-of-liability clause caps the freelancer's financial exposure to the total amount paid under the contract. Without one, a small project could theoretically create unlimited liability. Standard practice is to include one in every freelance agreement.

Scope management: preventing the slow bleed

Scope creep does not happen all at once. It happens one small request at a time. "Can you also make a version for mobile?" "While you are in there, can you update the footer?" "Oh, one more thing — can you also write the copy for this page?" Each request is small. In aggregate, they double the project. Your intake form should establish the framework for managing scope before the first request arrives.

• Change request process — how are changes beyond the original scope handled? A simple rule: any work not described in the original scope requires a written change request with a cost estimate and the client's approval before work begins. Document this process at intake so the first time you send a change request, the client already agreed to the workflow.
• Scope creep warning signs — "just one more thing," "can you also," "while you are at it," and "this should be quick" are the four phrases that precede unpaid work. Your intake form cannot prevent a client from saying them, but it can establish that additional requests trigger the change request process.
• Approval gates — what needs sign-off before proceeding to the next phase? A design project might have approval gates at wireframe, mockup, and final. A development project might have gates at architecture review, staging deploy, and production deploy. Gates prevent the most expensive kind of rework — the kind where you built the wrong thing because nobody reviewed the foundation.
• Communication cadence — weekly check-in, daily standup, or async updates? The right cadence depends on the project length and the client's management style. A two-week sprint needs daily updates. A six-month retainer needs weekly summaries. Establish the rhythm at intake.
• Project completion — what constitutes "done"? A final delivery checklist, a handoff process, and a definition of what the client receives at the end of the engagement. "The project is complete when the client has received all deliverables listed in the scope section, in the specified file formats, and has approved the final versions in writing." Without a definition of done, projects drift indefinitely.

Building your freelance business on solid intake

The freelancers who thrive long-term are not necessarily the most talented. They are the most organized. They are the ones whose clients know exactly what they are getting, when they are getting it, what it costs, who owns it, and what happens when things change. Every one of those answers should be captured at intake — before the first hour is billed, before the first file is opened, before the first deadline is set.

A thorough intake process does not slow down your client onboarding. It accelerates it. When a client fills out a form that asks about revision rounds, kill fees, IP ownership, and deployment access, they understand they are working with someone who has done this before. That is the foundation of a professional relationship — and professional relationships are the ones that generate referrals, repeat work, and rates that reflect your actual value.

Related guides

• Web Design Intake Forms — what web designers and developers need to capture at project kickoff.
• Graphic Design Intake Forms — brand guidelines, creative direction, and approval workflows for design engagements.