Enterprise purchases often involve several people making different decisions. Daily users describe the work; procurement coordinates the process; technical reviewers assess integration and risk; budget owners check resources; and an authorized approver confirms the commitment. For an overseas supplier, map each role’s questions, evidence, and next step instead of guessing from seniority. The examples below are hypothetical; confirm each company’s actual process with the customer.
Who will use the product or service day to day?
Users put a product or service into a daily workflow, or receive its output and handle what happens next. Start with one task: what triggers it, what steps happen now, who provides inputs, who gets the output, and where work stalls? Ask the customer to walk through a recent example and name the person responsible for each action. “Our team needs this” may blur user, manager, and approver needs. Across departments, compare usage, workload, the consequences of errors, language or time-zone needs, and responsibility for training and exceptions. A contact’s title alone does not establish whose needs they represent.
Agree on observable acceptance conditions before discussing supplier features. For an order handoff, for example, what information is required, who may see it, how soon must it be completed, and who handles missing details? Describe the work result so users can identify the actual constraint.
Suppose a team wants to improve customer-data management. Sales may create records, operations maintain lists, and managers use reports; they may disagree about required fields, update frequency, and access. Have a daily operator walk through the current workflow and exceptions, then rank the two most important changes. If a manager answers for users, mark the requirement “pending user confirmation.” Ask two users to describe the same process: differences may reflect separate departmental rules or a missing shared process. For any feature request, ask what situation it addresses, what workaround is used, and what result would be acceptable. Record the need in a sentence users can verify.
Who coordinates the procurement process?
A procurement contact often turns a business need into comparable steps and approvals, but may not control the budget or select the supplier. Ask who gathers departmental needs, prepares specifications, requests quotes, arranges supplier reviews, tracks contracts and purchase orders, and follows up on deadlines. Have the contact describe a similar purchase from proposal through activation; note each handoff and why work was returned. If “procurement handles it,” clarify who coordinates the process and who owns the business need.
Use a small table to capture assumptions for the customer to correct:
| Role | Typical task | Evidence to check | Direct question |
|---|---|---|---|
| Business contact | Gathers work needs | Requirements document | Who defines the scope? |
| Procurement coordinator | Tracks process steps | Process checklist | Who arranges the next review? |
| Approver | Confirms an authorized step | Approval record | Who completes this approval? |
Treat this as a working map, not an organization chart. One person may cover several roles in a small company; a large company may split supplier registration, security review, and contract steps by team or region. Record names, departments, actions, and next handoffs. If a name is unavailable, record the function and how an introduction might happen.
A supplier can help with a clear requirements summary, comparable scope options, and a missing-document list, but should not presume the customer’s process or authority. If no route exists, sketch known steps and ask which reviews are mandatory, which can run in parallel, and who provides each document. This separates process delays from poor fit and internal review time from supplier commitments. Track versions and recipients; after meetings, recap the next owner and response. If the coordinator cannot confirm timing, ask who can.
What will technical reviewers examine?
Technical reviewers assess how a proposal connects to the customer’s environment, how data moves, and who might be affected by failure or incorrect access. Establish whether the review covers architecture, accounts and permissions, data types and retention, connections to existing tools, operational support, continuity, and exit arrangements.
Instead of asking whether something “will pass security,” ask which documents are required, who reviews them, and what could block a trial or launch. Technical staff may assess compatibility while security or data-governance colleagues assess risk. Keep those responsibilities distinct.
Describe exchanged data types, transfer direction, users, areas of responsibility, and unknowns in a format the customer can assess. Label each point confirmed, awaiting customer information, or requiring further assessment. Before a demonstration or test, confirm the permitted environment, test-data rules, participants, stop conditions, and who records results or raises blockers. If a reviewer asks whether data leaves a customer-designated region, check the architecture evidence. If it is unavailable, log the question, assign an owner, and leave it unresolved.
Separate requirements into “must have,” “acceptable alternative,” and “not yet confirmed.” For an unmet requirement, ask whether another workflow is possible, who can accept the risk, and whether evaluation should stop. For a met requirement, record the document or test result that supports it. A successful demonstration does not establish that formal review is complete. Suppliers should explain only what they can substantiate; customer reviewers interpret customer policies.
Who manages and approves the budget?
Distinguish the person proposing a purchase, the budget manager, and the approver. A finance colleague may check a process or account code without deciding to buy. Ask which cost center would fund the purchase, whether a budget line exists, what information approval requires, when reviews occur, what currency is used, and who confirms annual or multi-year arrangements. Thresholds, approval rules, and accounting treatment vary by company, so confirm them with the customer.
Separate quoted scope, one-time work, recurring charges, internal effort, integration or training, renewal, and exit costs. Mark each item quoted, estimated, or customer-owned. The lowest price may not fit, especially when costs sit across departments.
For illustration, suppose an option costs 1,000 billing units per month plus a one-time setup charge of 2,000 units. Its known first-year cost is 1,000 × 12 + 2,000 = 14,000 units. If the department’s assumed available amount is 13,000 units, discuss scope, timing, or another resource source. These hypothetical figures are not market prices.
Ask whether the comparison contains the fields needed for a decision, what evidence is still needed for submission, and who will provide it. Record “budget reviewed” separately from “budget approved”: review means someone has seen or assessed the information; approval requires confirmation of the formal step and any remaining conditions. When useful, compare two scope options and show what each includes, excludes, and changes. If no budget is set, ask when it can next be reviewed.
Who can confirm the final decision?
Several people may own different decisions: selecting the business option, approving funds, signing a contract, or confirming that delivery can begin. Clarify what “decision” means, then ask who owns each action, who must participate, what evidence is used, and what completion condition applies. Do not infer approval from seniority, meeting leadership, or frequent email replies. “The direction looks right” is not a purchase commitment.
Summarize your understanding for correction: “The business team confirms the need, this contact completes the technical assessment, this role approves the budget, and an authorized signatory handles the contract. Is any review required first?” Ask who can formally confirm approval. If there is a committee, clarify whether it recommends, selects jointly, or has approval authority; a meeting conclusion may still need authorization.
Track statuses such as “recommended,” “pending approval,” “approved,” “ready to sign,” and “ready to activate,” with the person who confirmed each and supporting evidence. Suppose a sales manager prefers an option while finance still checks resources and technical review is unfinished. Record the preference as known and the budget and technical conditions as open, with an owner and requested response for each. If no approver is identified, mark the role unknown and ask for the formal process contact.
If the approver cannot attend, ask the authorized contact how to submit the proposal, what criteria apply, and the current status. Get confirmation from someone with authority before treating the commitment as complete. An email copied to someone is not evidence of signing authority.
How should you ask when a role is missing?
Identify whether the gap concerns the work, the knowledge, or decision authority. Without users, requirements may be inaccurate; without a technical reviewer, risk questions may remain open; without a budget owner or approver, resources and commitment cannot be confirmed. Tie each gap to the decision it blocks.
Make a low-effort request the contact can forward. For example: “To prepare materials for your internal review, who confirms the data flows? Could we include them for twenty minutes, or should I send a document for them to review first?” Explain the purpose and agenda so the introduction does not feel like another sales pitch.
If a name or meeting is unavailable, ask about the responsible function, review sequence, required documents, and whether a written answer will do. Offer a one-page summary to forward. Avoid unnecessary personal information, and do not ask one contact to answer for a specialist on unconfirmed points.
After each follow-up, update the map with what is known, its source, what is missing, who will follow up, and when a reply is expected. No reply means “pending.” Combine recurring departmental questions in one tracked list to prevent conflicting versions. Rather than send a long questionnaire, start with the gap blocking progress and offer an introduction, written response, or short meeting. If internal information cannot be shared, record only the disclosed process status and next confirmation point.
Before the next meeting, place known contacts on a simple relationship map and write one question for every unconfirmed role. Ask the main contact to identify the right person or an acceptable way to confirm the answer. You can also visit the Chan & Chung website for brand information, then plan the discussion around the customer’s actual process.