Client deliverables: what belongs on the list.

Client deliverables are the finished things you hand over and the client keeps: the eight edited episodes, the twelve help center articles, the logo files. They're the part of everything you produce that the buyer can point at, count, and ask for one more of, which is the reason each of them needs a number and a unit price next to its name in the document both sides sign. Everything else you make on the way there, the transcripts and the moodboards and the internal review notes, is working material that stays yours unless you've agreed otherwise in writing.

That division does more work than it looks like it should. An agency that writes its list carefully can answer a week-four request in one short reply, because the answer is already sitting in the signed scope as arithmetic. An agency that writes "social content and supporting assets" has agreed to something nobody can measure, and the argument about whether the next ask was always included starts the moment the client sends it.

What are client deliverables?

A client deliverable is anything the engagement produces that ends up in the client's possession as a finished item, named and counted in the scope, and accepted by them on some stated test. All three parts of that are load-bearing, and dropping any one of them is how a list stops settling arguments. Naming it stops two people picturing different objects. Counting it decides what a second one costs. The acceptance test decides when your obligation on that line is discharged and the clock stops running.

The cleanest way to tell whether something qualifies is to imagine the client emailing to ask for another. If "can we get one more of those" is a sentence both of you would instantly understand, it's a deliverable and it belongs on the list with a unit price. If the same sentence would produce a puzzled reply, you're looking at either a task or a piece of working material, and putting it on the list only invites a conversation you can't price. We've written elsewhere about what makes a project deliverable billable, and the test is the same one applied to a narrower set.

What's the difference between a client deliverable and your own work product?

The difference is who can order another one. A client deliverable is something the client has bought a specific quantity of, so a request for more is a priced change. Work product is the material you generate to get there, and the client has bought the result rather than the process, so asking for more of it is asking for something that was never quantified and has no unit.

The published guides split this differently, and their splits are built for project managers rather than for people sending invoices. Adobe's guide on project deliverables divides them into internal and external, and again into tangible and intangible, and again into process and product. Teamwork's glossary entry leads with internal versus external and adds a product versus project distinction. Each of those is a real taxonomy and none of them tells you what to write on the page a client signs, because they classify deliverables by where they sit in a project rather than by whether somebody can ask you for a second one.

So the practical split for an agency is narrower. Is the item something the client is buying a quantity of, or is it a by-product of doing the work? Wireframes, discovery notes, competitive research, the shot list, the edit project file and the working spreadsheet are usually the second kind. They can become deliverables, and on some engagements they should, but only by a decision you make on purpose and write down with a number next to it.

If the client can ask for another one, it's a deliverable, and it needs a price.

What goes on a client deliverables list?

Whatever the client is buying a quantity of, described in the words they'd use, and nothing else. On most agency engagements that's between three and eight lines, which is far fewer than the number of things the team will actually produce. A brand project might list the identity system, a set of applications and a guidelines document. A website build lists unique page templates, pages built from those templates, forms and content entry. A content engagement lists articles, revisions and a distribution calendar.

Consulting work follows the same rule with less obvious objects. The countable thing is usually a document or a session, so a diagnostic report, a costed recommendation set, a financial model and two workshops make a list, while "a growth strategy" doesn't, because nobody can tell when a second strategy has been requested. The same trap catches creative work whenever a line is written as an outcome instead of an object, and a creative brief settles direction without settling quantity, which is exactly why the brief and the scope have to travel together. Putting a rate beside each answer in the brief closes the same gap a section earlier.

Three things routinely get put on the list that shouldn't be. Status reports and project plans belong to running the project rather than to the client's purchase. Source and working files are a separate decision with their own price. Anything expressed as a percentage improvement or a business result depends on the client's own behavior, so promising it as a deliverable hands them a line you can't control.

How do you write a deliverable line a client can't read two ways?

Give it a name, a count, a unit rate for the next one, and the test that makes it accepted. Four elements on one line, and the line stops being a description and becomes something you can do arithmetic with in front of a client. Here is a real list written that way, for a six-week podcast launch.

Read section 3 as a client and there's nothing left to interpret. Eight episodes means eight, a ninth costs $1,150, and an episode is finished when Ingleby says so or when five working days pass in silence. The four subtotals add up to the fee, so nobody has to trust a single round number, and the rates in section 4 are agreed at the point when neither side knows yet who will need them. That last detail is the whole reason to print rates early, and it's the same argument behind putting the rate card inside the signed statement of work rather than in an email you'll have to go and find.

Who owns the client deliverables after you hand them over?

Usually the client, on payment in full, but only for the items you can actually transfer, and a list of deliverables is not by itself a transfer of ownership. Three categories behave differently and they're worth separating in the contract rather than sweeping into one clause. The finished deliverables you made from scratch can genuinely change hands. Anything licensed from a third party, a font, a stock track, a plugin, is licensed to whoever holds the license and can't be given away by you. Your own reusable material, the component library and the templates you bring to every project, stays yours, and the client gets the output rather than the machinery.

This is where the familiar clause promising the client "all work product and materials" on final payment quietly overpromises, and we've gone through the specifics of that in the context of who owns what at launch on a web build. The safe version names the three categories and says plainly what happens to each. It takes four sentences and it prevents the last-week conversation where a client asks for the font files.

What happens when a client asks for something that isn't on the list?

It gets priced off the rates already in the document, sent for written approval, and started only once that approval comes back. In week four Ingleby's owner asks for a bonus episode with a guest tea grower, plus a second set of audiograms cut for a retail partner's channels. Nothing about the request is unreasonable and there's no reason to say no to it.

Off section 4 the reply takes about a minute. One additional produced episode at $1,150, one additional show notes page at $290, and six additional audiograms at $180 each for $1,080, which is $2,520 and moves the final two episodes back by four working days. The project goes to $20,370, the owner approves it in the same thread, and the conversation stays administrative because nobody is inventing a number under pressure.

Without those lines the same request is a judgment call made at five in the afternoon, and the judgment call usually goes the client's way, because arguing costs more than absorbing. Absorbed, it's $2,520 of unbilled production on a $17,850 engagement, which is 14.1 percent of the fee given away on a request that took thirty seconds to make. Doing that twice a year across a handful of projects is the arithmetic behind what scope creep actually costs an agency.

Your deliverables list is the part of the scope a client rereads

Nobody goes back to the introduction or the payment terms once a project is running. The deliverables list is different, because it's the one section both sides pull up mid-project to settle what was agreed, and it usually gets read in a hurry by somebody who is mildly annoyed. That's the reader it has to work for, which means the count and the unit rate belong on the same line as the name, where they can be found in one glance rather than assembled from three sections.

Section 3.2 above is the model: eight produced episodes, at $1,150 each, accepted on confirmation or five business days. A reader who has never met your team can price a ninth episode from that line alone, and so can you, which is what makes the reply to a week-four request a short one. When the counts and the rates are somewhere else, or nowhere, the same request becomes a negotiation you didn't plan to have and usually lose. Worth reading next: how deliverables and milestones divide the invoice, and why an exclusion is only half written without a price.

Frequently asked questions