How to Present Selections to Clients: A Builder's Communication Guide
Walk into any builder's office and you'll find some version of the same problem. There's a spreadsheet somewhere called "Selections_FINAL_v3_USE THIS.xlsx". The client is texting about the floor tiles they approved two weeks ago. And a subcontractor is on hold because no one can confirm which tapware was selected for the ensuite.
The selections are all there. They're just scattered across email threads, PDF attachments, a shared Google Drive folder the client can't navigate, and the builder's memory.
This guide is about fixing that — not with a complex system, but with the specific practices that actually work when you're running a real build and trying to keep clients informed without creating more admin for yourself.
How most builders present selections today — and where each method breaks
Before looking at what good looks like, it helps to understand exactly why the common methods fall apart.
Emailed PDF attachments
The PDF is the default. You build the selection schedule in a spreadsheet or Canva template, export it, and email it to the client. They reply with questions, you update the schedule, export again, send again.
The problem isn't the PDF format — it's the version control that email attachment delivery creates. By the time you're on the third revision, there are at least three versions of the schedule in the client's inbox, and they don't all agree. If the client goes back to an old email and references the wrong one, you have a problem.
The other issue is images. A PDF without product photos is just a list of product codes. Clients can't approve something they've never seen — and a text description of a tapware finish ("matte black", "brushed nickel") doesn't communicate nearly as much as a photo does. Most builders know this and either spend significant time sourcing images manually, or skip them and accept the extra client questions that follow.
Shared Drive folder
Google Drive or Dropbox solves the "emailing multiple versions" problem, but it introduces a different one: navigation. You know what's in the folder. The client doesn't.
Most shared Drive folders evolve organically — a supplier quote gets added here, a revised schedule goes in there, some product images end up in a subfolder. After a few weeks, it's a filing cabinet your client has never been trained to use. They won't find what they're looking for, they'll call you to ask where it is, and you've created a support burden out of what was supposed to be a communication tool.
There's also no clear approval mechanism. "I'll put the latest schedule in the Drive folder" doesn't tell the client what action they need to take or how to signal they've approved it.
Printed selections
Some builders still present selections in person with a printed document — especially at a formal selections appointment. Done well, this is actually a strong method. You walk the client through each item, get their sign-off on paper, and walk out with a completed schedule.
The problem is what happens next. That signed paper document is a snapshot. The build evolves, the client changes their mind on two tiles, a product gets discontinued. Now your reference document is out of date, but the client signed it and remembers approving those original tiles. Disputes follow.
Printed schedules work for the initial sign-off meeting. They don't work as the ongoing communication tool for a build that spans six to twelve months.
The version-control problem: 'which version is latest?'
This is the single most common source of miscommunication on a residential build, and it comes up in almost every method described above.
The version-control problem has a specific shape. It isn't that builders are disorganised. It's that selections are a living document — they change throughout the build — but the delivery mechanism (an email attachment, a printed PDF) is static.
Every time you send a new version, you create a new "authoritative" copy. But the old copies don't disappear. They sit in the client's inbox, in the shared folder, in the contractor's downloads folder. Any of those could get referenced. Any of those could get used to order the wrong product.
The file naming convention builders reach for ("FINAL_v4_updated_USE THIS ONE") is itself evidence that the underlying system is broken. You're adding metadata in the filename because the file format can't carry version information.
There are three consequences that show up regularly:
Wrong products get ordered. A contractor references an old version of the schedule and orders the first tile that was selected, not the one the client changed their mind to three weeks later. The client notices when they visit site. Everyone loses time and money.
Change order disputes. The client insists they changed something. You can't find any record of approving it, and neither can they. Without a clear revision history showing who changed what and when, the dispute becomes a conversation about who has the better memory.
Rework. The worst outcome. A trade completes work based on outdated selections. The correct version was in the email from two weeks later, but nobody flagged it. The work has to be undone.
For more on why selection schedules managed in spreadsheets are particularly vulnerable to this problem, see our breakdown of where the spreadsheet approach breaks down.
What a modern workflow looks like
A workflow that actually works has three properties: a single source of truth, visible revision history, and a clear client approval mechanism. Here's what each of those looks like in practice.
A single live link, not a series of attachments
Instead of emailing a new PDF every time selections are updated, the client gets one link that always shows the current version of the schedule. When you update a selection, the link updates. There's no "which version is latest?" question because there's only ever one version.
This is how client portals work in purpose-built selection schedule software — and it's also achievable with a carefully managed shared Google Slides or Notion document, though those tools add their own friction. The key property is that the URL never changes and the content behind it is always current.
The practical benefit extends beyond the client. When a contractor needs to verify a selection, you send them the same link. When you're on site and a subcontractor asks about the tapware, you pull it up on your phone. One source, accessible to everyone who needs it.
Revision history that's visible to everyone
Every change to a selection should be logged — what changed, when, and why. Not buried in an email thread, but attached to the line item itself.
This does two things. First, it creates accountability. If a client changes their mind on tiles for the third time, there's a record of all three decisions. If a contractor installs the wrong product, you can establish exactly when the correct selection was confirmed. Second, it gives your client confidence that they're seeing everything. When clients can see that a selection was updated on a specific date because they requested a change, they trust the schedule more.
Revision history also protects builders from the variation disputes that are most difficult to resolve: the ones where both sides genuinely believe they're right. A timestamped log of selections and approvals is the closest thing to an objective record you'll have.
Client-visible approval status
There's a difference between presenting selections and getting selections approved. Most builders present well. Fewer have a clear mechanism for getting explicit client approval that leaves a paper trail.
Effective approval workflows give the client a specific action to take — approve this item — and record when they took it. This can be as simple as a column in your schedule that shows "Pending", "Approved" or "Changes requested", visible to both you and the client. Or it can be a formal sign-off via a selections appointment, captured in writing.
What doesn't work as an approval mechanism: "the client replied to my email saying the tiles looked good." That's ambiguous, undated in relation to the selection schedule, and difficult to reference later.
The goal is to make it easy for clients to say yes — and to make the "yes" mean something.
Presenting selections in stages, not all at once
One of the biggest mistakes builders make with client communication is presenting all selections at once. 300 line items across flooring, tiles, tapware, electrical, appliances, joinery and finishes is genuinely overwhelming. Clients either rush through it to feel done, or they freeze and delay decisions that the build needs to move forward.
Stage your presentations to match when trades need information. Wet areas first. Then electrical. Then joinery and appliances with long lead times. This isn't just better for the client — it's better for the build, because the items that need to be locked in early actually get locked in early, and the client isn't expected to make good decisions about light fixtures before they've even decided on their flooring.
See what is a selection schedule for more detail on which selections need to be finalised at each stage of the build.
How Swatcha helps today
Swatcha is a selection schedule builder for residential builders. The current product solves the two most labour-intensive parts of the problem above: sourcing product images and producing a polished, on-brand schedule document.
Every item you add pulls a product image automatically, which removes most of the manual work of scraping supplier websites or saving photos from emails. Export the schedule as a PDF and the client-facing document is ready in seconds. The template is consistent across projects, so clients always see the same format and your team always produces the same quality output.
Live shareable links are next on the roadmap — with client-visible approval status and automatic revision history to follow. None are live yet, so until they ship, version control and formal sign-off still need to run through your existing process (see the checklist below). Swatcha takes care of building and presenting the schedule; the ongoing approval loop is something you're still running manually.
If you're currently managing selections in a spreadsheet or putting together a Canva template for each project, the immediate win is the time you get back on image sourcing and formatting.
The practical checklist
If you're improving your client selection communication without a full software change, these are the highest-leverage things to fix first:
Consolidate to one location. Pick one place — a single shared document, a single shared folder with one master file — and make it the place. Not "one place per project" with inconsistent naming. One place, same structure, every project.
Add product images to every item. This is the single biggest driver of client questions and approval delays. Clients approve what they can see. A product code is not something they can see.
Number your revisions. Every time the schedule changes, increment the revision number and update the date. This doesn't require software — it just requires discipline.
Create a formal approval step. At a minimum, ask for a written confirmation (an email is fine) that the client has reviewed the current revision and approves it. Reference the revision number in the email. Keep those emails.
Stage your selections presentations. Don't send everything at once. Send what's needed for the next stage of the build, get it approved, then move to the next stage.
Document every change. When a selection changes, note what it changed from, what it changed to, and why. Even a note in a spreadsheet comment is better than nothing.
Frequently asked questions
What is the best way to present selections to clients?
The most effective approach combines a clear visual format — product images, not just codes — with a single live link your client can return to at any time. Avoid emailing PDF attachments as your primary delivery method: each new version creates a "which one is latest?" problem that wastes everyone's time. A shared link with revision history and client-visible approval status removes the ambiguity entirely.
How do I get clients to approve selections faster?
Present selections in digestible batches rather than all at once, and make the approval action obvious — a clear "approve this item" action or a signed PDF confirmation, not just a thumbs-up reply in an email thread. Attaching product images to every line item dramatically reduces the back-and-forth because clients can see exactly what they're approving, not just read a product code.
How do I handle it when a client changes their mind after approving selections?
Document the change formally and update the revision number. The key is having a timestamped record of when the original approval happened and what was changed. This protects both you and the client — it's the evidence you need if a variation charge is disputed. Tools with built-in revision history make this automatic; a shared spreadsheet does not.
Should I present all selections at once or in stages?
In stages, always. Group selections by the order trades need them. Wet area tiles and tapware need to go first because your tiler and plumber need lead time. Electrical and lighting come next. Joinery and appliances with long lead times need to be finalised well before lock-up. Presenting 300 selections in week one is overwhelming and leads to rushed decisions — or worse, indecision that holds up the build.
What should a client-facing selection schedule include?
At minimum: product name, supplier, finish or colour, a product image, and the room or area it applies to. Add a cost column if you're tracking against a budget allowance, and an approval status column so you can see at a glance what's confirmed and what's still outstanding. The image column is non-negotiable — without it, your clients are approving product codes they've never seen.
