Build an Expansion Conversation From Adoption Evidence
Use customer supplied evidence before proposing an additional capability.
An expansion conversation begins with work already underway. Account notes might show report activity, meeting attendance, or support requests. Those records help you prepare, yet records do not explain why someone opened a report or which decision followed. Start with evidence from people who perform the work. Ask an operational owner to walk through one recent moment when the current service informed a choice. Listen for the person involved, the information reviewed, the action taken, and work left unresolved after action. Your goal involves understanding a workflow before suggesting a new purchase.
Choose one workflow before a meeting. A broad request for feedback often leads to broad praise or broad frustration. Neither response gives a manager useful direction. A narrow invitation produces detail. Say, “Your team reviews payment reporting each morning. Please show me last Tuesday’s review. Which question did your lead need answered, and what followed?” The customer selects a screen, report, or record for discussion. Their answer supplies evidence without asking anyone to accept your interpretation. Begin with a time, an owner, and a real work item rather than a general opinion.
In a fictional practice situation, River Street Market uses a daily payment report. Dana, an operations lead, opens the report around 9:00 each morning. She looks for refunds awaiting attention, then sends a short note to a support colleague. The report supports a regular routine. A login record alone says far less. Ask Dana, “When a refund appears, what do you review before sending your note?” Her reply might identify two fields, a time check, and a separate customer record. You now have a starting point for useful discussion.
Keep observed facts separate from your reading of those facts. “Dana reviews the report each morning” becomes an observed fact after Dana confirms her routine. “Dana values faster refund handling” is a possible reading, not yet a fact. Test your reading with a direct question. Say, “You check two places before sending a note. Which part of this step adds effort for your team?” A reply such as “We look up each case in another record” describes friction. A reply such as “We prefer this review” changes your next question. Either response deserves equal care.
Record where each statement came from. During a call, make a small evidence record with a date, a speaker, an action, and the speaker’s description of friction or value. Label every line observed, reported, or open question. “Dana reviewed the morning report on Tuesday” belongs under observed after her confirmation. “Eli searched a customer record before replying” belongs under reported when Eli describes his work. “Would a shared case view reduce review time?” belongs under open question. This simple separation prevents a tentative idea from becoming an unsupported claim in your notes.
Avoid treating every gap as a sales opening. A gap might need a clearer handoff, a local process decision, or a discussion with another owner. Name uncertainty before anyone assumes a solution. Say, “I heard a manual lookup occurs after report review. I do not want to assume an additional service addresses your problem. Who should join us to map this step?” The customer retains control of discovery, and you avoid describing scope before a relevant option receives verification. A careful pause protects trust better than a rushed proposal.
Bring people performing adjacent work into discussion. Dana’s support colleague, Eli, handles customer messages after Dana flags a refund. In another fictional practice situation, Eli says his main delay happens when a case arrives without a clear note from operations. A proposal focused only on reporting would miss his concern. Ask Eli to describe two recent cases in order. Which record arrived first? Who added context? Where did work pause? A sequence gives more useful detail than a broad opinion about efficiency.
Ask for one example with a routine path and one with an exception. Routine work often hides the details which cause delay on a difficult day. Dana might show a refund where every field appears in the report. Eli sends a reply soon after her note. For a second refund, Dana sees a missing reference and opens another record before contacting Eli. Ask what prompted her search, where she found the missing information, and whether Eli knew a search had happened. Such questions map decision points without claiming why they exist.
Do not use login counts as proof of value. A high count might reflect training, repeated attempts, routine checking, or several people sharing a task. A low count might reflect a weekly process with real importance. Ask about context before drawing a conclusion. Say, “I noticed report activity on several mornings. Does every review follow one process, or do some days need a different response?” The answer might point to a weekly exception meeting, a month end close step, or a task owned by a different team. Let the customer define meaning.
When you hear a possible expansion signal, slow down before discussing scope. Restate the workflow in plain language and request correction. Say, “Dana reviews refunds, then Eli looks up each customer case before replying. Does this describe your current process?” Pause for edits. Then ask for priority. “If your team changed one part of this process, which part matters most?” One customer might choose better context for support rather than a new report. Another might say no change deserves attention now. Each answer gives a sound basis for your next action.
Commercial discussion belongs after problem definition. If an additional capability appears relevant, describe only verified information. Name what you know, what needs confirmation, and who owns each answer. For example, say, “We documented a manual lookup between reporting and customer response. I will confirm whether available options address this workflow. You will decide whether a review with your support lead deserves time.” Do not present a capability as included in an agreement unless a proper source confirms scope. Do not attach outcome claims to a workflow nobody has tested.
Set a focused review session. Invite Dana, Eli, and an owner responsible for customer records or refunds. Send a short advance note: “Please bring one recent refund case. We will trace report review through customer response, identify where work pauses, and decide whether further evaluation deserves time.” Each person arrives with a clear purpose without pressure to agree with a proposal. At the meeting, guide one case from start to finish. Ask for facts before interpretations, then write corrections beside your evidence record.
Use a fictional practice schedule to test your preparation. Dana opens a Monday refund at 9:10, identifies a case, and sends Eli a note at 9:18. Eli opens a separate record before replying at 9:31. Ask Dana which information she needed at 9:10. Ask Eli what information was missing at 9:18. Record their answers without adding a solution. Before the meeting closes, Dana agrees to send one comparable refund case by Thursday. Put a thirty minute comparison meeting on the following Tuesday, name Dana and Eli in the invite, and attach the evidence record for correction.
Practice these next
Use local usage evidence and input from lab owners to understand uneven adoption without directing customer staff.
Use user feedback to understand adoption problems before prescribing training or directing laboratory staff.
A customer success conversation for contact center leaders who see uneven use of a new workflow.
Validate account narratives with the customer team before presenting value.
Use observed capacity to support an honest scope and adoption discussion.
Pair product signals with customer context before recommending a renewal path.