Professional Presentation Design Scope of Work Template

Project Overview

A short summary of the presentation project: the client's business context, the purpose of the deck (fundraising pitch, sales presentation, conference keynote, internal board update, or product launch), the intended audience, and the presentation's overall goal. This section also names the presenter, since a deck designed for a founder pitching investors reads very differently from one designed for a sales rep running a live demo, and it names the actual decision-maker who signs off on the final version, since a deck approved by a single founder moves through revisions very differently than one routed through a five-person marketing committee. Most disputes over a finished deck trace back to a mismatch between the audience the designer imagined and the audience the client actually presents to, so this section exists specifically to close that gap before a single slide layout is drafted. It should also note how mature the starting material is: a client handing over a polished outline with talking points already grouped by slide needs far less structural work than one handing over a raw brain-dump of bullet points, an old deck that needs a full rebuild, or nothing more than a verbal description of the pitch, and the price and timeline in later sections should reflect which of those three the project actually starts from. A strong overview also states the desired tone (data-heavy and analytical, visual and narrative-driven, or a hybrid) and any hard constraints, such as an existing corporate template the deck must extend rather than replace, a livestreamed event with a fixed screen resolution, or a physical venue with a projector aspect ratio the design has to accommodate. Recording all of this in one place before kickoff means the designer isn't reverse-engineering the brief from a single Slack message midway through the first draft, and it gives both sides a single document to point back to if the project's goals shift partway through, rather than relying on memory of a kickoff call that happened weeks earlier.

Deliverables & Slide Count

The specific outputs the designer will provide: a locked slide count (for example, 18 slides across the core narrative plus a 5-slide appendix), the files the client receives (a master editable deck plus a presentation-ready PDF export), and whether the deliverable includes speaker notes, a printed handout version, or a shortened 'teaser' version for email outreach. This section should separate the core deck from optional add-ons, such as an animated build for a live keynote versus a static version for asynchronous sharing, since those two formats require materially different production time, and it should state whether a one-page executive summary or a follow-up email version of the deck is bundled in or billed separately, since clients frequently assume a 'deck' automatically includes a condensed leave-behind for people who weren't in the room. Listing slide count explicitly, rather than describing the deck only by topic ('cover slide, problem, solution, market, team, ask'), prevents the single most common presentation-design dispute: a client who expected a fuller deck receiving a tighter one that technically covers every topic but in far fewer slides than they pictured. It's worth naming the appendix separately from the core narrative too, since appendix slides (detailed financials, technical architecture, case study backups) are typically priced and revised on a lighter touch than the slides a presenter actually clicks through live, and conflating the two counts inflates the perceived slide count on both sides of the negotiation. Where a deck is being built from an existing corporate template rather than from scratch, this section should also distinguish 'new' slides that require original layout work from 'templated' slides that reuse an existing master layout with new content dropped in, since the two take very different amounts of design time even when they end up looking equally polished in the finished file, and pricing that doesn't separate them tends to undercharge for custom work while overcharging for template-based slides. This distinction also affects the Revision Policy below, since a client requesting a full redesign of a 'templated' slide is effectively asking for new work, not a revision, even though the request might read the same on paper as a minor tweak to a custom slide.

Content & Asset Responsibilities

What the client must supply before the designer can start, and what the designer is responsible for creating from scratch. Client-supplied inputs typically include raw copy or bullet points for each slide, existing brand guidelines and logo files, any data or charts that need to be visualized, product screenshots, and headshots or team photography. Designer-created inputs typically include layout, iconography, custom illustration or diagram design, chart and data visualization styling, and any stock photography or icon licensing needed to fill gaps. This section should also draw a line around copywriting: whether the designer is only formatting content the client provides, lightly tightening it for slide-length readability, or actually writing the narrative from a rough outline, since that last option is a materially different (and usually separately priced) service that a design-only SOW shouldn't quietly absorb. Naming this split in writing matters because the single biggest cause of missed deadlines on presentation projects isn't design time, it's waiting on the client to deliver final copy, and a scope of work that states 'client delivers finalized slide content by [date]' gives the designer grounds to adjust the timeline when that date slips, rather than absorbing the delay silently. It's also worth specifying the format the client should deliver content in (a single organized document with slide-by-slide sections, rather than a scattered mix of email threads, voice memos, and half-finished spreadsheets), since content that arrives disorganized effectively shifts information-architecture work onto the designer without it ever being priced as such. Finally, this section should note who is responsible for fact-checking data, statistics, and figures that appear on slides, since a designer who visualizes a chart is not in a position to verify whether the underlying numbers are correct, and a scope that's silent on this can leave a designer holding responsibility for a client's own data errors after the deck has already gone out.

Format, Software & File Specifications

The technical specifications generic creative-services scope-of-work templates almost never mention, but that make or break a presentation-design handoff: the source software the deck is built in (PowerPoint, Google Slides, Keynote, or Figma), the aspect ratio (16:9 widescreen is now standard, but 4:3 is still requested for some legacy projector setups), whether animations, slide transitions, and morph or build effects are included in or excluded from the base price, whether the final file is a fully editable master template the client's own team can update after handoff or a locked, presentation-only file, and the licensing terms for any stock photography, icon sets, or custom fonts used in the design. Presentation design is unusually format-sensitive compared to other creative deliverables: a logo file works the same whether it's opened in Illustrator or Affinity Designer, but a deck built with PowerPoint's native animation engine will not carry its motion, transitions, or dynamic charts over cleanly if exported to Keynote or Google Slides, and a client who assumes otherwise discovers the problem only after the project is already 'finished.' It should also state which version of the source software the deck targets, since a deck built with a current PowerPoint feature (a live-linked chart, a newer transition style, a variable font) can render incorrectly, or silently drop that feature, when opened in an older version on the client's own machine, and a designer who tests only in their own up-to-date environment can miss that gap entirely. This section should also cover accessibility and delivery details most SOWs skip entirely: whether slides need alt text and sufficient color contrast for screen-reader and colorblind viewers, whether embedded video or audio is supported by the chosen software and how large those files can be before email or upload limits become a problem, and whether the client needs a live, editable cloud link (a shared Google Slides file the team can keep updating after handoff) rather than a static export that goes stale the moment the roadmap changes. Spelling all of this out here, rather than leaving it implied, is what actually prevents that conversation from happening after delivery instead of before kickoff, and it's precisely the layer of specificity that separates a presentation-design SOW from a generic graphic-design or branding SOW repurposed for slides.

Brand & Visual Direction

How the deck should use the client's existing brand identity: which brand colors, fonts, and logo variations apply, whether the designer is extending an existing brand template or building a new visual system specifically for this presentation, and how much creative latitude the designer has to deviate from brand guidelines in service of a stronger visual narrative. This section should also cover reference decks or mood boards the client has shared as inspiration, whether a co-branded partner or investor logo needs to appear alongside the client's own, and whether the deck needs a dark-mode or light-mode variant for different presentation environments. It should state whether the final deck needs to work as a standalone leave-behind (meaning every slide has to make sense without a presenter narrating it, with more on-slide text and fuller explanations) or purely as a live-presentation aid (meaning slides can be sparse and visual, since the presenter is doing most of the talking and dense slides would compete with them for the audience's attention). Those are fundamentally different design briefs even when the topic and slide count are identical, and conflating them is a frequent source of client dissatisfaction with an otherwise well-executed deck, since a leave-behind reformatted at the last minute into a live-presentation aid, or vice versa, rarely reads well in either direction without real rework. Finally, this section should note the presenter's visual comfort level: some presenters want dense, information-rich slides they can lean on as a script, while others want the opposite, minimal slides that force them to speak from memory, and designing to the wrong end of that spectrum produces a technically polished deck the presenter is nonetheless uncomfortable delivering on stage.

Revision Policy

How many rounds of revisions are included in the price (commonly two full rounds plus one round of minor polish), what counts as a revision versus a completely new creative direction, and what happens once the client requests changes beyond the included rounds. For presentation design specifically, this section should distinguish between slide-level revisions (adjusting layout, copy, or color on existing slides) and structural revisions (reordering the narrative, adding or removing entire slides, or changing the deck's core argument), since the latter functions closer to a new project than a tweak and is usually priced or scoped separately, for example an extra structural round billed at a flat rate rather than folded into the included rounds at no charge. It's also worth specifying a revision request format (a single consolidated document or comment thread rather than a scattered string of one-line emails after each slide is viewed), since disorganized feedback is one of the biggest hidden time costs on any deck project, and setting a response window (such as revisions returned within three business days of receiving consolidated feedback) keeps both sides accountable to the timeline agreed in the next section rather than letting an open-ended 'whenever you get to it' revision round quietly stall the whole project. It's also worth defining who on the client side has final sign-off authority for each revision round, since feedback that arrives from three different stakeholders with conflicting opinions, none of whom has been named as the decision-maker, is one of the most common ways a two-round revision policy quietly turns into five rounds without anyone agreeing to that expansion.

Timeline & Milestones

The estimated project duration (a typical mid-size deck runs one to three weeks from kickoff to final delivery, depending on slide count and revision rounds) broken into milestones: kickoff and content collection, first draft delivery, feedback and first revision round, second revision round if included, and final file delivery. A useful pattern for a two-week engagement is to allocate roughly the first third of the timeline to content collection and outline approval, the middle third to the first full draft, and the final third to revisions and file delivery, since front-loading content collection is what actually keeps the back half of the schedule from slipping. For time-sensitive decks, such as an investor pitch ahead of a fixed fundraising deadline or a keynote tied to a specific event date, this section should also state what happens if the client's own delays (late content, delayed feedback) push against that fixed date, so the designer isn't held to an unmovable deadline for a delay outside their control, and it should note whether a rush fee applies if the client needs the entire timeline compressed after the SOW is already signed. It's also worth naming an outline or skeleton-deck checkpoint before the first full visual draft, where the presenter approves the slide-by-slide flow and rough content before any layout or design time is spent, since catching a narrative problem at the outline stage costs a fraction of what catching it after twenty polished slides have already been built costs in wasted design hours, and it's a step most freelance and agency timelines skip in the rush to show visual progress early.

Payment Terms

The total project cost, the payment structure (commonly a 50 percent deposit to begin work and 50 percent on final delivery for smaller decks, or a three-way milestone split, for example 30 percent at kickoff, 40 percent on first-draft delivery, and 30 percent on final approval, for larger or longer-running decks), and how additional slides or revision rounds beyond the agreed scope are billed, whether as a flat per-slide rate or an hourly rate for structural changes. This section should also state the invoicing currency and accepted payment methods, the late-payment policy (a fixed grace period before a late fee or a pause in delivery applies), and what happens if the project is paused or cancelled partway through, including whether the deposit is refundable and whether the client receives partial or draft files in that case rather than nothing at all. For agencies working with retained clients on recurring decks (monthly board updates, quarterly investor letters, ongoing sales collateral), this section can also reference a retainer or block-of-hours arrangement instead of a per-project fee, with unused hours either rolling over or expiring at a stated interval, and it should note who owns the master template built during the first engagement so later decks in the series don't get re-billed as if they were starting from a blank file. Naming the currency matters more than it seems for cross-border freelance and agency work, since an unstated currency on an invoice is a routine source of disputes once exchange rates move between the quote and the payment date.

Confidentiality & Ownership

Presentation decks routinely contain a client's most sensitive material: unreleased financials, fundraising terms, unannounced product roadmaps, or competitive strategy, which makes a confidentiality clause more relevant here than on most other design projects. This section should state that the designer will not share, publish, or reuse the deck's content (as distinct from the underlying design template or layout system, which many designers reasonably retain rights to reuse across clients), when full ownership of the final deck transfers to the client (typically upon final payment), and whether the designer may list the engagement in a portfolio, and if so, whether that requires the client's prior written approval given how much confidential business information a deck typically contains. It should also cover what happens to working files and drafts once the engagement ends, since a designer holding onto an outdated version of an investor deck on a personal laptop months after a fundraising round closed is a real exposure most creative SOWs never think to address, and, for agencies, whether this confidentiality obligation flows down to every contractor or freelancer who touches the project, not just the primary signatory. A well-scoped clause also distinguishes an ordinary confidentiality obligation, which lives inside this SOW and covers the specific deck, from a standalone NDA, which is worth signing separately and in advance whenever the client needs to share sensitive figures just to get an accurate quote, before either party has agreed to move forward with the project at all. Where cloud storage or a shared drafting link is used, this section should also state how long draft files stay accessible after delivery and who is responsible for deleting them once the engagement is formally closed out.