Role Play Script About Selling a Product: A Full Example With Dialogue and Rubric

A role play script about selling a product is a written dialogue between two roles, usually a seller and a buyer, that walks through a realistic sales conversation from the opening line to the close. Unlike a generic sales pitch template, a full script includes both sides of the exchange: what the seller says, how the buyer pushes back, and how the seller responds to that pushback.

Teachers use these scripts in business communication or marketing classes to teach persuasion and negotiation. Sales managers use them during onboarding so new reps hear what a good discovery-to-close conversation actually sounds like before they try it live. The format works because it removes the guesswork: instead of telling someone "handle objections well," you show them exactly what that looks like line by line.

A good product sales role play script usually has three parts: character setup (who the buyer and seller are, and what the buyer's situation is), the dialogue itself, and debrief notes that explain why certain lines worked.

Before you hand out the script below, spend five minutes on setup. It matters more than the dialogue itself, because a role play only teaches something if the people running it understand why each character is acting the way they are.

Here is a complete, usable buyer-seller role play script. The product is a project management app called TaskFlow, but the structure works for almost any B2B or B2C product, you just swap the details.

**Setup:** Maya (seller) works for TaskFlow. Devon (buyer) manages a 12-person marketing team currently using spreadsheets and email to track projects. Devon has tried one other tool before and thought it was too complicated for the team to adopt.

**Maya:** Hi Devon, thanks for making time. Before I show you anything, can you walk me through how your team tracks projects right now?

**Devon:** Sure. We use a shared spreadsheet and a lot of Slack messages. It works, mostly, but things fall through the cracks when we're busy.

**Maya:** How often would you say something falls through the cracks, roughly?

**Devon:** Honestly, at least once a week. Usually a deadline someone forgot about because it was buried in a thread.

**Maya:** Got it. So the spreadsheet tracks the work, but it doesn't actually remind anyone or flag when something's at risk.

**Devon:** Right, exactly.

**Maya:** That's the gap TaskFlow is built for. Every task has an owner and a due date, and the app sends a warning two days before something's late, so it surfaces before it becomes a missed deadline instead of after. Given what you just described, would that have caught last week's issue?

**Devon:** Probably, yeah. But I'll be honest, we tried a tool like this last year and the team hated it. Too many clicks, too much setup.

**Maya:** That's a fair concern, and it's the number one reason teams abandon these tools. Can I ask what specifically made it feel like too many clicks?

**Devon:** Just creating a task took like five fields. People stopped bothering.

**Maya:** That makes sense. TaskFlow's task creation is one field: type the task and hit enter, everything else is optional. I'd rather show you than describe it, would a 15-minute walkthrough with two or three of your team members work, so you're not the only one judging whether it's actually simple?

**Devon:** That's reasonable. What does it cost for a team our size?

**Maya:** For 12 people it's $8 per person per month, so $96 total, and the first two weeks are free so your team can test it on a real project before anyone pays for it.

**Devon:** Okay. Let's set up that walkthrough. Can you do Thursday?

**Maya:** Thursday works. I'll send a calendar invite with the two people you mentioned included.

Look back at the script above and notice that Maya never argues with Devon's objection about the team hating the last tool. Arguing with an objection makes the buyer defend it harder. Instead, the script follows a four-part pattern that's worth teaching explicitly.

First, acknowledge the objection as reasonable ("That's a fair concern"). Second, ask a specific follow-up question instead of assuming what went wrong ("what specifically made it feel like too many clicks?"). Third, respond to the actual answer with a concrete difference, not a generic reassurance. Fourth, move to a small, low-risk next step, a short walkthrough, rather than asking for a purchase decision on the spot.

This pattern works for price objections, timing objections ("we're not ready to switch systems this quarter"), and authority objections ("I'd need to run this by my director") the same way it works for the adoption objection in the example. Acknowledge, ask, answer with specifics, propose a small next step. When you write your own role play script about selling a product, build every objection around this sequence instead of writing a rebuttal speech.

If you're using this in a classroom or a formal training session, score the seller's performance on specific behaviors rather than a vague "communication" grade. A rubric with concrete criteria also makes the debrief faster because everyone is pointing at the same moments in the conversation.

The TaskFlow example above is written for a mid-level rep or an intermediate student, but the same structure adapts easily. For beginners, remove the price objection and keep only the adoption objection, so learners can focus on one skill at a time. For advanced practice, stack two objections back to back, for example price and a competitor comparison, so the seller has to prioritize which one to address first.

To adapt it to a different product, keep the four-part shape: a discovery question, a buyer answer that reveals a specific pain point, a pitch that connects the product feature to that exact pain point, and one realistic objection tied to the buyer's situation rather than a generic "it's too expensive." A sales role play script for a physical good, like office furniture or a subscription box, follows the same shape, only the discovery questions and objections change to match what that buyer actually cares about, such as delivery time or return policy instead of software adoption.

The most common mistake is skipping the buyer's role card and letting the person playing the buyer invent objections on the spot. Without a defined situation, buyers tend to either cave immediately or stonewall for no real reason, and neither teaches anything useful.

The second mistake is running the role play only once. A single pass tells you whether someone can follow a script, not whether they can adapt it. Running the same scenario with a new objection, or swapping who plays the buyer, shows whether the underlying skill transferred.

The third mistake is debriefing on feel ("that felt good") instead of on the rubric. Tie every comment in the debrief back to a specific line in the conversation, and the group will retain far more than a general "nice job" or "work on your closing."

Not every classroom or team has a practice partner available on demand, and a script only builds confidence once you've said the lines out loud, not just read them. This is where SayNow AI is useful as a companion to the script above: you can speak the seller's lines in response to a simulated buyer, get feedback on pacing, filler words, and clarity, and repeat the objection-handling exchange as many times as you need until the acknowledge-ask-answer-propose pattern feels automatic. It won't replace running the exercise with a real partner in class, but it's a solid way to rehearse before you're graded or before a real sales call.