Handle Stakeholders Who Disagree on the Technology Problem

When operations and a technology team disagree, a seller faces a trust risk. A fast response might flatter one group, deepen a dispute, and make another group less willing to share information. Begin with respectful listening instead. Each person often sees a different portion of daily work. Operations sees delays, rework, and workarounds. Technology sees current setup, access rules, service records, and competing priorities. Both accounts deserve a fair hearing before anyone proposes a cause.

Do not begin by asking who is right. Ask what each person observed. Replace labels such as “the system fails” or “people resist change” with examples tied to a task. Ask when an issue occurs, who performs work, what appears before a step, what follows, and which record supports their description. Specific questions move a group away from competing stories and toward a shared picture. A seller does not need a verdict during an early conversation.

Say, “I hear one concern about daily work and another about current system setup. Let us describe one recent case from start to finish.” This language acknowledges both views without declaring a winner. Ask every participant to describe their part of one case. Comparison often reveals whether disagreement concerns product behavior, process design, access, training, handoffs, or a separate business choice. Choose one case familiar enough for people to recall concrete details.

Prepare before a joint conversation. Read earlier notes and separate direct observations from your own interpretation. Write each view in neutral language. Operations might report two manual status updates before a customer receives an answer. The technology team might report no recent service interruption and say current configuration supports an approved process. Neither statement proves a cause. Both statements identify an area worth reviewing. Neutral notes help participants recognize their words without feeling judged.

Invite people who see work from different positions. An operations manager might describe a queue. A front line user might show actual steps. A technology administrator might explain setup. A reporting owner might show where delays appear in existing records. Ask the buyer for a small working group with direct knowledge of one chosen workflow. Too many participants create noise and turn a fact review into a debate about past meetings.

In a fictional practice situation, a support director says agents spend twenty minutes each morning copying open requests into a spreadsheet. The technology manager answers, “Our platform stores every request. We do not see a technical issue.” An account executive says, “Both observations help. Which requests are copied, what decision depends on the sheet, and where does an agent obtain each value?” The director explains supervisors use the sheet to assign urgent requests. The manager explains an existing report exists, yet supervisors lack access.

The discussion now has a narrower question. Why do supervisors lack access to a report used for assignment? Possible reasons include access setup, a workflow decision, or training. Do not diagnose from one call. Propose a fair observation step instead. Agreement on a question matters more than agreement on a cause at this stage. People who entered with opposite views now have a defined piece of work they agree deserves inspection.

Agree on one test both sides accept. A useful test has a defined workflow, a small evidence set, and a clear question. In the fictional situation, the group agrees to watch one supervisor assign requests using the existing report. They note available fields, missing fields, and when the spreadsheet enters the process. The observation occurs Thursday morning with the support director, technology manager, supervisor, and solutions consultant present. Put time, participants, and purpose in a shared calendar invitation.

Use shared language in every invitation and note. Avoid words such as failure, blame, broken, or resistant. Write, “We will review the assignment workflow and compare available report fields with information supervisors use.” This gives every participant a reason to attend. Such wording avoids a hidden agenda where one department expects the session to prove a prior claim. A neutral title also makes later notes easier to share with people who missed the session.

Before observation, ask what evidence would change each person’s view. The support director might say access to the existing report would remove copying. The technology manager might say a new request is unnecessary if missing access explains delay. Record these statements beside each person’s name. They reveal decision criteria without forcing agreement before evidence exists. They also show whether a system review or a process adjustment deserves attention after people inspect the workflow.

During the session, keep a visible fact record. Write task step, person performing work, information used, and source. Mark unanswered questions as unanswered. Do not fill gaps with a sales explanation. If a supervisor says, “I do not know why this field stays empty,” record those words and assign follow up. A careful record protects trust after a meeting, especially when each group expects a different conclusion. Read notes aloud before moving from one step to another.

Ask permission before introducing product discussion. Once people see current workflow, they might request options. Do not turn an evidence session into an unsolicited demonstration. Say, “Would a separate conversation about possible approaches help after your group reviews these findings?” This gives buyers control over sequence and protects shared observation from feeling staged. If they decline, respect their choice and focus on sending a complete record for their internal review.

Some disagreements reflect a decision problem rather than a technology problem. Operations might seek faster response while technology must limit changes during a busy period. Those goals do not cancel each other. State both goals plainly, then ask who decides the tradeoff and when. A useful next step might involve a person responsible for service priorities and change timing. Do not claim a tool resolves a business choice without a buyer’s own review.

If someone presses for a verdict during an early meeting, slow down with a clear boundary. Say, “We have two useful observations and one planned test. I do not want to label a cause before we see this workflow.” This response still moves work forward. Follow with date, participants, and exact question for observation. A named step shows respect for urgency while keeping a conclusion tied to evidence rather than pressure from a senior voice.

Afterward, send the fact record to all participants. Ask each person to correct wording inside a defined review window. Separate agreed observations from interpretations needing more evidence. Schedule a decision conversation around the question people now share. In the fictional situation, report access becomes the first topic. Any product discussion waits until the group confirms whether access changes supervisor assignment work. Keep the record available for new participants who join later.

At 9:00 on Thursday, the fictional account executive opens a shared note with four columns: action, person, information source, and open question. As the supervisor assigns the first request, the executive records report name and missing access. Before people leave, the executive sends a Friday review invitation, asks the technology manager to check supervisor permissions, and asks the support director to bring one completed spreadsheet row for comparison.