Discover the agent desktop before proposing change

A customer care director complains that agents juggle too many screens, and the easy response is to sketch a lighter desktop on the spot. That response skips a step. Before anyone proposes fewer screens, someone needs to know which screens exist, why an agent opens each one, and what happens if that screen disappears. The conversation below shows how to get those facts before any fix gets proposed.

Why this conversation goes wrong

When a customer care leader says agents use too many screens, the sentence sounds like a request for a demo. It is not. It is a symptom report, and symptoms have several possible causes. An agent might switch screens because a payment tool sits outside the case system, because a knowledge guide has no search function, or because a supervisor requires a second login for approval. Each cause calls for a different fix, and none of them show up if the conversation jumps straight to a product walkthrough.

An account executive who reaches for a demo early trades a real answer for a comfortable one. A demo lets both sides agree that switching screens looks bad, without anyone learning which switch actually costs time. The director feels heard, the account executive has a story to bring back internally, and the next call starts from the same vague complaint. Nobody leaves with facts a design review can use.

How to prepare before the call

Ask for one thing before the call, a single recent case the customer care leader can walk you through step by step. A general description of the workflow will not do. You need one order question, one billing dispute, one account change, something specific enough that the leader has to name each screen instead of describing the setup in broad terms.

Ask who else should join. A supervisor who fields agent complaints daily brings detail a director several layers removed will not have. A systems owner who understands access rules and integration limits catches claims that are technically wrong before they get built into a plan. Getting both people on the call costs a small amount of scheduling effort and saves a large amount of rework later.

Resist the urge to prepare a diagnosis. You are not there to explain why the screens multiplied or to suggest a fix. Your job on this call is to map what happens now, not to cut screens by the end of the hour. The same discipline applies elsewhere. See how to Frame an audit trail request as an evaluation question for another case where the fix is to ask a sharper question, not to answer the one you were handed.

What to say

Marcus, a customer care director, opens with the complaint. "My agents keep seven windows open just to answer a simple order question," he says.

Rina does not defend the product or pitch a fix. "Walk me through one recent order question from start to finish," she says. "I want to know every moment an agent leaves the main case screen."

Marcus describes the flow. An agent opens an order tool to check shipment status, switches to a payment portal to see the charge history, and pulls up an internal guide to check the return policy.

Rina narrows the question. "Which one of those steps causes the longest delay," she asks, "and does the agent have the authority to finish that step alone?"

Marcus says payment disputes route to a separate queue, so the agent has to hand the case off and wait for another team. He had been thinking about screen count. He had not thought about who owns the decision.

"That handoff is worth more attention than the screen count," Rina says. "Could we sit in on a few approved cases with your operations lead and your application owner? We should map how the work actually moves before anyone proposes what to remove."

Marcus agrees, and the call ends with a plan for observation sessions instead of a product demo.

Mistakes to avoid

A few habits sink this kind of call. Offering a fix before you finish mapping the work is the most common one. Even a soft suggestion, such as mentioning that other clients cut their screen count in half, shifts the conversation from discovery to sales and shuts down the details you still need.

Accepting the director's explanation as the full picture is another. Directors describe workflows from a distance. They know the complaint, not always the mechanism behind it. If Marcus says the payment step is slow, ask why it is slow rather than writing it down as settled fact.

Counting screens instead of counting decisions costs you the real insight. The number of applications open matters less than how many times an agent has to stop, switch context, and wait for someone else to act. A workflow with five screens and no handoffs beats a workflow with three screens and two approval waits.

Skipping the systems owner leaves gaps you cannot see. A supervisor tells you what agents feel. A systems owner tells you what the systems allow. Without both on the call, you end up recommending changes that break an integration nobody mentioned.

Promising an outcome before you have the facts locks you into a number you cannot defend. Saying you can get the director down to two screens sets a target before you know whether two screens is even right for this workflow.

How to practice and score it

The best way to get comfortable with this call is to run it before you run it for real. Have a partner play the director and describe a workflow complaint out loud, using whatever frustration and vague language a real leader would use. Your job is to draw the case on a blank page as the conversation happens, marking every application, every decision point, and every handoff the partner mentions.

When the conversation ends, look at the page, not at how the conversation felt. Count the handoffs you found. Note whether you asked who owns each decision. Check whether you named a systems owner and a supervisor as people who should join a follow up session. If your page only lists application names with no decision points, your questions stayed too shallow.

Score yourself, or have a manager score you, on three things. Did you resist naming a solution during the call. Did you get a specific example instead of a general description. Did you end the call with a plan to observe real cases rather than a plan to build something. A call that scores well on those three points gives the next stage of the sales process a map worth designing against.

DealSpeak builds this kind of rehearsal directly, giving you a counterpart who plays the frustrated director and holds back details until you ask the right question. Running the same scenario more than once, with the counterpart varying its answers, trains you to ask about ownership and handoffs by habit rather than by memory. You can find more scenarios like this one among the Contact Centers practice conversationsincluding one that shows how to Uncover callback policy limits in a service evaluation.

Map first, propose second

A workflow complaint is an invitation to ask better questions, not a cue to demo a product. Get the specific case, name the people who know the access rules, and leave the call with a map instead of a promise. The design review that follows will be shorter and more accurate because of it.