Work With a Buyer Evaluating an Integration Partner
Clarify whether the partner choice, product choice, or project ownership is the real issue.
When a buyer says they need an integration partner before moving forward, do not hear only a request for a name. The request might point to an unclear implementation plan, missing internal capacity, an unresolved system owner, or concern about accountability after launch. A quick introduction feels responsive, yet might place the buyer with someone whose experience or availability does not match the work. Start with the project behind the request.
Ask what the partner would own. Encourage the buyer to describe work in plain terms. They might need help mapping data, configuring a connection, coordinating internal teams, testing a workflow, training staff, or supporting a launch plan. Ask which tasks stay with internal employees and which tasks they expect outside help to cover. This distinction prevents a partner conversation from becoming a vague substitute for project planning.
Then ask about the systems involved and the people who own them. “Which internal system creates the most uncertainty?” “Who approves changes within each system?” “Who will answer technical questions during testing?” A buyer might know the desired connection but lack access to the people needed for implementation. Bringing those owners into early scoping often matters more than selecting a partner first.
Ask how the buyer will judge fit. A request for “your best partner” offers no usable selection rule. Invite the buyer to name experience, working style, capacity, location, language, project timing, or responsibility areas which matter to them. Do not fill in criteria from your own assumptions. One team might need someone who joins planning early. Another might value knowledge of an internal system. A clear scorecard turns a referral into an evaluation.
Consider a fictional example at Norwood Supply. Elena leads a program to connect a newly purchased service with an existing order system. She says her team needs a partner before procurement will continue. A seller asks what work she expects from the partner. Elena first says, “The integration.” After a few questions, she explains her internal team owns access approvals and testing, while outside help should map fields, coordinate technical sessions, and document the connection for future staff.
The seller asks who owns the order system and whether the owner has reviewed the project. Elena admits no owner has joined an evaluation call. The partner choice is important, though the more immediate gap is internal participation. Elena agrees to invite the order system manager into a scoping session. This gives an outside partner a fair view of the work rather than asking them to guess from a sales conversation.
Prepare a one page scoping brief before any introduction. Include the business purpose, systems named by the buyer, work the buyer expects outside help to own, work held internally, known dates, open questions, and named participants. Mark unknown items as open rather than quietly guessing. The brief gives each potential partner enough context to respond honestly. The buyer also sees where planning needs more detail.
In a joint scoping conversation, establish who speaks for each part of the project. The buyer should explain priorities and selection criteria. Internal system owners should explain access, dependencies, and their available time. The potential partner should explain how they would approach the stated work and what information they need before offering a plan. The seller keeps the purpose clear and records questions which need follow up. No one should promise a schedule or outcome before the people doing work have reviewed scope.
Use direct questions during the meeting. “Which task would you own from start through handoff?” “What input do you need from Elena’s team before work begins?” “What would cause you to revise the proposed sequence?” “Who signs off on testing?” Specific questions expose different assumptions before they become delays. They also help the buyer compare partners using the same project facts.
Do not present a referral as an endorsement of every aspect of a future project. A partner might have relevant experience, yet only the buyer and partner decide whether the scope, timing, and working relationship fit. State this when you make an introduction. “I am connecting you because your stated scope includes order system mapping. Please use your selection criteria and scoping discussion to assess fit.” This language is honest and leaves room for questions.
Keep commercial and technical discussions separate when helpful. The buyer might need an initial technical conversation before any commercial proposal makes sense. They might also need internal approval before sharing details. Ask which sequence fits their process. Do not advise on legal or procurement requirements. Instead, ask who owns those reviews and what information they need from the project team. This keeps momentum without stepping into decisions outside your role.
After each scoping session, send a factual recap. List the tasks discussed, remaining questions, owners, and next meeting purpose. Do not write “partner selected” unless the buyer says so. In the fictional Norwood example, the recap says Elena will confirm data access ownership, the order system manager will provide a sample field map, and the potential partner will return questions about testing. Each item has a named person and a date chosen during the call.
If the buyer speaks with more than one partner, help them use the same comparison structure. Their scorecard might include understanding of stated scope, questions raised during scoping, availability for the proposed period, approach to collaboration with internal owners, and clarity about assumptions. Avoid ranking partners yourself unless your organization has an approved process for such guidance. Your role is to help the buyer gather comparable information for their own choice.
Watch for signs of a project reset. Conflicting views of ownership, no internal system owner, a changing business purpose, or an undefined testing path deserve attention before another introduction. Say what you heard. “We have not yet named who approves testing. Would you prefer to settle the question before meeting another partner?” This protects the buyer’s time and gives the evaluation a more stable starting point.
Practice with a fictional sponsor who asks for a partner during a short call. Ask four questions before naming anyone: what work needs outside ownership, which system creates uncertainty, who owns internal access, and how the sponsor will judge fit. Then state the next meeting purpose in one sentence. Your practice partner should challenge one assumption so you learn to record an open question rather than defend an early answer.
For your next partner request, send the buyer a scoping brief with blank fields for internal owner, outside scope, testing approval, and selection criteria. Ask them to complete those fields with their project team. Use the returned brief to set a joint conversation where the first agenda item is the buyer’s own definition of a suitable partner.
Practice these next
Address a technical limitation directly and move the buyer toward a workable decision.
Give a buyer a realistic review path without making compliance commitments yourself.
Understand access risk, user experience, and operating ownership before discussing IAM tools.
Prepare reviewers with context and assigned experts before the meeting begins.
Prepare a handoff giving the technical buyer confidence and retaining business context.
Follow up on a security review without chasing people who are overloaded.