Sell to the Accidental Techie Through a Clear Handoff

Ask About the Work They Have Inherited

Start with a recent request: "Can you walk me through what happens when someone needs IT help?" Ask where that request goes and what the prospect must do before it reaches a technician. Write down the current handoff rather than assuming the office manager is the obstacle.

Then ask: "Which part takes you away from the job you were hired to do?" Let them identify the burden. They may want technical work transferred while keeping purchasing approval or staff coordination.

Don't describe them as helpless or insist they abandon the process they understand. You need their knowledge of how the business works. Check what should stay with them as carefully as what should move to your team.

Say a hypothetical 20-seat company uses its office manager to coordinate new employees' equipment. The useful sales conversation is about which preparation the MSP can own and which employee details or approvals must still come from the client. A product list doesn't resolve that handoff.

Respect the Authority They Actually Have

Ask: "Have you been asked to choose the provider, recommend an option, or coordinate the review?" The answer tells you what support this person needs from you. Confirm any further approval without treating their title as proof that they cannot decide.

Jeff Loehr recounts a CEO explicitly delegating MSP selection to an office manager, followed by a seller insisting on the CEO anyway. He recommends respecting that delegation and working with the participant. That is his sales advice, and it is a useful correction to title-based qualification.

I don't buy generic sales advice that tells an MSP to get past the office manager. That person may hold delegated authority and understand the daily service need. Bypassing them on an assumption can also leave your proposal missing the workflow the MSP would inherit.

If another approver is involved, use: "What will they need to compare, and how would you like us to bring them into the discussion?" Work through the current contact. Don't turn an introduction into a way to remove them from the decision.

Show the Handoff in the Offer

I'd put the current task beside the responsibility you're proposing to take. Have delivery check that proposed responsibility before sales promises it. The office manager should be able to see what changes without decoding your stack.

These are discussion points, not a package to promise unchanged to every prospect. Fill the responsibilities from the service you can deliver. Name the route for work that requires a separate quote or falls outside the managed agreement.

The model favors a flat monthly fee with clear inclusions, exclusions, and separately quoted prices. Use that structure to explain the offer. A promise to handle IT needs a boundary the client can recognize and the service desk can follow.

Give Them Words They Can Take to the Approver

You can summarize the proposal this way: "Our team would own the technical work described here through this request route. Your team would keep the approvals shown beside it. These items need a separate decision before we can schedule them." Replace each description with the agreed scope.

Keep that summary short enough to use in an internal discussion. Include the actual price and service commitments from your checked proposal, not a second version of the offer created for the meeting. If the scope changes, update both.

Need a useful question before sending it? Ask: "Could you use this to explain what changes in your working day?" If the answer is no, rewrite the unclear responsibility with them before asking for an introduction or a decision.

Don't ask the prospect to resolve a technical uncertainty for you. Assign the assessment to someone qualified, with the client's authorization and the scope clear. Keep credentials out of the sales conversation and use the approved access process if assessment work proceeds.

Answer the Objection Without Removing Their Control

If the prospect says, "I still need to know what is happening," try: "Let's agree which updates and approvals you need. We can own the technical action while keeping you informed through the route shown here." Offer that only where it matches the service your team can provide.

If they say, "It will take longer to explain it to someone else," answer: "Let's take a request you already handle and map the information our team needs. Then we can check whether the proposed process removes work or just moves it around." Use the result to revise the proposal.

If they say, "I can do some of this myself," use: "Which responsibilities do you want to keep? We'll check the remaining scope and price it clearly." Don't argue that their knowledge is the problem you are selling against.

Check the handoff with delivery rather than assuming every retained task creates a saving. A shared arrangement still needs someone to own the technical outcome and the exceptions. Cost that arrangement before offering a different price.

Make the First Next Step Concrete

Agree what information or assessment is needed before the offer can be finalized. Name who supplies it and what your team does with it. Keep the prospect's business knowledge in the process without leaving them responsible for inventing the technical scope.

Close with: "Here is the work we propose to take, the decisions you keep, and the question we still need to resolve. Who should own that next step?" Record the answer in the opportunity so the delivery conversation can pick it up.

Start with the inherited task the prospect wants to change. Show how a real request would move through your proposed service, then let them correct the boundary. That is a more useful offer than a promise that they will never have to think about IT again.