How to Handle a Podcast Guest Who Wants a Segment Cut After Recording

Every podcast producer eventually gets the message. The episode is recorded, the transcript is back, maybe you have already started rough editing, and then a guest reaches out asking you to cut a specific segment, a joke that landed wrong, a stray comment about a former employer, a number they were not supposed to share on the record. It is a completely normal part of running an interview show, and honestly it is usually a sign your guest trusts you enough to ask rather than just quietly refusing to promote the episode. The problem is not the request itself. The problem is that almost every team handles it the same chaotic way, over a text message or a stray email that gets buried in a thread with forty other things, with no record of who approved what, no timestamp locked to the actual cut, and no way to prove later that the guest actually signed off on the final version that went out.

We built this process because we kept watching podcast and video teams lose these requests in exactly that gap. Someone texts the host, the host forwards a screenshot to the editor, the editor guesses at the timestamp, and three weeks later nobody can remember if the guest approved the final cut or just complained about the rough one. That is not a workflow, that is basically a game of telephone with your show's credibility riding on it. At the end of the day, a guest-requested cut is an editorial decision with real consequences, and it deserves the same documented approval trail you would want for a client sign-off on a paid production.

Why Just Text Me The Timestamp Breaks Down

Text messages disappear into scroll history. Emails get buried under subject lines that do not mention the episode name. And even when the request does get written down somewhere, it almost never includes the one thing that actually matters, which is a timestamp tied to the specific cut of the file the editor is working from. A guest might say cut the bit about the lawsuit around the fifteen minute mark, but if the editor is working from a version with a different intro length, that fifteen minute mark is now wrong. For instance, we have seen editors cut the wrong thirty seconds entirely because the guest was timestamping off the raw Zoom recording while the editor was working from an already-trimmed rough cut. Nobody did anything wrong on purpose. The process just had no shared reference point, right, and shared reference points are exactly what a scattered text thread cannot provide.

Set The Expectation Before You Ever Hit Record

The easiest way to avoid a messy after-the-fact negotiation is to tell guests, before recording starts, exactly how the review and cut-request process works. A short line in your pre-interview email does most of the work: something like, after we record, you will get a private review link where you can leave timestamped comments on anything you would like reconsidered, and our editor will respond to each one before the final cut goes out. That single sentence changes the entire dynamic. Instead of the guest wondering whether to text the host at 11pm or email someone whose address they do not have, they already know a link is coming and that their notes will be tracked. It also protects your team, because a guest who was told up front how the process works is far less likely to claim later that their request was ignored.

Turn The Request Into A Documented Review Comment

Once recording wraps and you have a rough cut, the move is to send the guest a private, timestamped review link rather than a raw export or a Dropbox folder. A proper Client Review Portal lets the guest drop a comment directly on the frame or second where their concern sits, which does two things at once. First, it removes all ambiguity about which moment they mean, because the comment is pinned to the actual timeline rather than described in prose. Second, it creates a permanent, timestamped, attributed record that exists independent of anyone's inbox. If a dispute ever comes up about what was requested and when, you are not relying on someone's memory of a phone call, you are pointing at a comment with a name and a date on it.

The Approval Loop From Comment To Confirmed Cut

Here is where most teams still drop the ball even after they start using a review link. A guest leaves a comment, an editor makes the cut, and everyone assumes the conversation is over. But the guest never actually confirmed the new version reflects what they wanted. Basically, a request is not resolved until the person who asked for it has seen the updated cut and said yes, this is right. That is why the loop needs a second pass: after the edit is made, the editor replies on the same comment thread with the updated timestamp or a fresh version link, and the request only gets marked resolved once the guest responds. This closes the loop in a way a text message thread almost never does, because in a text thread the last message is usually thanks so much rather than an explicit confirmation tied to the actual final file.

What To Do When The Request Comes In Days Later

Sometimes the ask does not come during the review window at all. The episode is already scheduled, sometimes it is already live, and a guest emails asking for something pulled after the fact. This is the scenario where having an existing review-link history really pays off, because you can pull up the original approval thread and see exactly what was reviewed, when, and by whom. If the original review link is still active, reopen it and have the guest leave the new request as a comment on the published cut rather than in a fresh email, so the record stays in one place instead of splitting across two systems. If your workspace uses Expiring Share Links for finished deliverables, generate a fresh time-limited link specifically for the post-publish request so you are not leaving an old review link open indefinitely. Either way, the same rule applies as before: no cut goes out the second time without an explicit, documented approval on the new version.

In workspaces we have looked at that run recurring interview shows and lean on a single tracked review link per episode rather than splitting requests across text, email, and DMs, guest-requested cuts tend to close in about a day instead of stretching across a week of back and forth, and that is not a small difference when you are trying to hit a weekly publish schedule.

Building A Standing Process Your Whole Team Follows

A good process only works if it survives the producer who built it going on vacation. Write down the steps somewhere your whole team can find them, not just in one person's head. That usually means a short internal doc plus a workspace setup that enforces the habit structurally, using an Approval Workflow that requires a resolved status before a file can move to final export, and a Multi Stakeholder Review setup if your show involves a host, a producer, and a network standards person who all need to weigh in before a guest-requested cut ships. According to No Film School, one of the recurring themes in post-production workflow advice is that the teams who struggle most are the ones improvising approval steps mid-project rather than deciding them in advance, and guest cut requests are exactly the kind of mid-project curveball that rewards having a process already in place.

• Pre-interview email mentions the review-link process before recording starts
• Rough cut goes out as a private timestamped review link, never a raw export
• Every guest comment gets an explicit reply, not just a silent edit
• Final approval is a specific yes on the updated cut, not an assumed one
• Comment history gets archived with the exported file for future reference

Why We Built PlayPause Around This Exact Problem

We built PlayPause because we were tired of watching teams reinvent this workflow badly, project after project, usually after something had already gone wrong. Frame accurate commenting, a resolved and unresolved status on every note, and a flat per-workspace price instead of a per-seat bill that punishes you for looping in a guest, a host, and a network exec on the same review link. That last part matters more than it sounds. A lot of review tools charge per collaborator, which quietly discourages you from adding the exact people whose sign-off actually protects you, and a guest whose cut request never gets logged because nobody wanted to burn a seat on them is a liability waiting to happen.

If you run a recurring interview show and you are still handling these requests over text, it is worth seeing how a proper review link changes the conversation. Compare the actual mechanics against a tool you might already know by reading PlayPause vs Frame Io, check PlayPause pricing to see the flat per-workspace model in full, or just head to PlayPause and start a workspace for your next episode. We also write regularly about production workflow on the PlayPause blog if you want more of this kind of process detail before you commit. At the end of the day, the guest who asks for a cut is not your adversary, they are trusting you to handle it properly, and a documented review link is how you prove you did.