Find the IT Buying Decision-Maker

Role labels are a discovery framework, not a claim that every organization uses the same titles or process.

Start with the problem owner

Ask who experiences the operational consequence of the current IT arrangement and who is coordinating the review. This person may be an internal champion, but their interest does not itself establish technical approval or authority to sign.

Ask: “What prompted a closer look now, and who else will need to be comfortable with any change?” Listen for stakeholders, not a title you expected to hear.

Find the technical evaluator

Identify who can validate systems, integrations, support expectations, security requirements and transition prerequisites. That may be an employee, an incumbent provider, an external advisor or more than one person. Clarify what evidence they will need and how it will be reviewed.

Keep discovery grounded in the actual environment: inventory, service expectations, backup and restore evidence, security controls and access ownership. Do not treat a broad “IT is covered” statement as verification.

Identify the signer and approval path

Ask who can authorize the agreement and what approvals precede that signature. Separate the person who recommends a provider from the person who can make a commitment. Confirm whether a board, parent entity or other authority is involved rather than assuming.

Never infer authority from seniority, job title or enthusiasm. Record the role and the individual's own description of the process.

Include finance and procurement early enough

Ask who reviews price, terms, vendor setup and purchasing requirements, and when their review enters the process. Learn which information is required, who provides it and what timing constraint is real. Do not label a process “stalled” simply because another team must review it.

Map roles, evidence and handoffs

Draw a simple chain: champion → evaluator(s) → finance/procurement → signer. Add a second person or shared role where appropriate. Beside each role, note their concern, evidence needed, next action, and who owns follow-up. Mark unknown roles explicitly and ask the champion how to include them respectfully.

Before presenting a solution, compare what each role needs with the service boundary and delivery reality. Resolve key compatibility, capacity, incumbent and transition questions first.

Illustrative example

In a hypothetical 70-person company, the operations director coordinates a provider review and is the champion. A systems administrator can confirm the Microsoft tenant, backup evidence and application dependencies, but does not sign. Finance checks the term and purchasing documents; the managing director approves the agreement. The next meeting is useful only if the technical evaluator's evidence questions and the signer’s approval steps are both represented—or deliberately scheduled.

Limits and unknowns

Role names and approval paths vary by organization. This framework cannot tell you who has authority at a specific prospect. Confirm roles directly, respect internal process and avoid implying that one friendly contact speaks for all stakeholders. It is not permission to use private community data or contact people without an appropriate basis.

Use communities for learning, not as a lead list. MSPGeek describes a free MSP community and links its forums and Discord (MSPGeek). The verified Tech Tribe vendor-policy page, modified February 20, 2026, permits helpful, directly relevant replies but prohibits promotional threads, blog-link drops, and indirect promotion (vendor policy); check rules before participating because they may change. MSPGeek's code of conduct bars vendor advertising in general channels and unsolicited commercial DMs, and says member data cannot be used outside the community without explicit permission. These rules do not establish buyer access or sales outcomes; no member data should be treated as a prospect list.

Next action

Record role, concern, required evidence and follow-up owner in the service-fit worksheet. If the incumbent and contract timing determine whether a change is feasible, use the respectful renewal conversation plan.