MSP discovery call questions template: intake before the quote
An MSP discovery call should end with a clear next step and a list of facts to verify before anyone commits to a quote.
The prospect says they have "about 50 users," everything is backed up, and the current provider will help with the handover. The account manager writes down 50 seats. Engineering inherits the word "everything."
Use these MSP discovery call questions to capture the business outcome, the likely service boundary, the people who can approve work, and the unknowns that could change the price. The copyable intake below works in your existing notes or PSA. It is built for the vCIO or account lead in a Connectwise Manage MSP that will own the client's RMM, Microsoft 365, and ongoing service relationship.
A first call produces reported facts. A technical assessment produces evidence. Keep both, with their sources, so a confident answer never quietly becomes an engineering assumption.
What should you learn before discussing a price?
Start with the event that brought the prospect to the call. A provider renewal, an acquisition, an unresolved incident, and a new office can all sound like "we need better IT." They create different work.
Ask:
- What changed, and what must work differently afterward? Capture the business process affected, the person who owns it, and what a successful result would look like.
- Why does this need to happen now? Ask for the actual renewal, move, audit, or operating deadline. Distinguish a hard external date from a preferred start date.
- What is working well enough to preserve? Record systems, vendor relationships, and service arrangements the prospect expects to keep.
- Who is affected when this goes wrong? Identify the business teams, locations, critical hours, and operational consequence. Avoid inventing a dollar value for downtime.
An answer such as "replace our MSP" still needs an outcome. "Warehouse staff need working scanners during the early shift" gives the assessment team something specific to investigate.
Which questions expose the service boundary?
You do not need to interrogate the prospect about every device. You need enough detail to identify what must be verified and who can supply it.
| Ask on the call | Evidence to request through an agreed secure channel | Why it changes scope |
|---|---|---|
| How many people, devices, sites, and shifts need service? Who works remotely or uses a shared device? | Current user, device, and site lists, with the source and export date | A seat estimate alone does not describe shared endpoints, servers, or support hours |
| Which Microsoft 365 tenants and domains are involved, and who administers them? | Tenant/domain list, license summary, and named administrative owner | Access, licensing, and tenant complexity affect discovery and transition work |
| Which applications stop the business if unavailable? Who supports each one? | Application list, dependencies, and vendor support contacts | A line-of-business vendor may need to approve or perform part of a change |
| What does the current provider manage? What does your internal team or another supplier retain? | Current service schedule and responsibility list | The new agreement must distinguish transferred, retained, and excluded services |
| What recovery outcome do you expect, and when was it last demonstrated? | Backup coverage and restore-test records for review | "We have backup" leaves recovery coverage, testing, and ownership unresolved |
| Which security, insurance, or customer-contract requirements apply? Who can supply the actual requirements? | Relevant requirements and named client owner | The team must assess the requirement before promising a control or compliance outcome |
| What contract dates, notice periods, or access dependencies affect a provider change? | Relevant agreement terms and handover contact | A desired start date may depend on another party's actions |
Request the minimum evidence needed for the next assessment. Agree who is authorized to share it and where it will be stored. Do not ask for passwords, recovery codes, tokens, or privileged access in call notes or an intake form. Technical access needs a separate authorized process.
CISA's guidance for MSPs and their customers calls for clear ownership of security responsibilities and explanations of services purchased, services excluded, and incident-response contingencies. Use the call to locate those decisions. Put the agreed responsibilities into the appropriate service documents after review.
Who can approve the work and the next step?
The person describing the problem may have neither spending authority nor permission to grant access. Capture both routes.
Ask who will approve the assessment, the service agreement, and any transition project. Find the technical contact who can validate the environment and the business owner who can accept an outcome. If procurement or legal review is required, record that dependency before promising a start date.
Discuss budget without turning a rough conversation into a quote:
"Is there an approved budget or planning range? Does that cover recurring service, the transition, and any remediation separately? Which of those still needs approval?"
Record the answer as the prospect's planning constraint. An available budget does not establish the cost of delivering the work.
Close with a concrete choice:
"The next step we recommend is an assessment of the items we could not verify today. Who needs to approve that, and when can we review its scope?"
Copy the prospect intake and unknowns log
Keep this record short enough that the next person will read it. Store sensitive evidence separately with appropriate access controls; link to it rather than copying it into general sales notes.
Prospect intake
Account / contact / call date:
MSP account lead:
Business outcome and affected process:
Trigger / required date / reason that date matters:
Success condition in the client's words:
Reported environment
People / endpoints / sites / operating hours:
Microsoft 365 tenants and administrative owner:
Business-critical applications and vendor owners:
Current provider / internal IT / retained suppliers:
Requested services / explicit retained responsibilities:
Contract and handover dependencies:
Requirements supplied by client / client requirement owner:
Decision route
Business approver:
Technical validator:
Budget status, recurring vs transition vs remediation:
Assessment approval owner and next review date:
Unknowns log: repeat for each material gap
Question or conflicting claim:
Reported answer and who supplied it:
Evidence needed / permitted source:
Evidence owner / due date:
Status: reported / requested / verified / conflicting
Potential effect on scope, timing, or price:
Next action and owner:
Disposition
Proceed to assessment / scoped paid discovery / pause or decline:
Why this route:
Deliverable and exclusions for the next step:
Client responsibilities and required approvals:
Next meeting / owner:
A blank field means the team still has a question. Do not fill it with the last client's configuration.
Should you assess, charge for discovery, or pause?
Use the unknowns log to choose the next deliverable. A call is enough to agree on that next step; it may be nowhere near enough to price the whole engagement.
| Route | Choose it when | Define before proceeding |
|---|---|---|
| Proceed to a technical assessment | The outcome is clear, the client can authorize evidence collection, and the assessment fits your agreed pre-sales process | Sections to review, evidence owner, access boundaries, and assessment output |
| Offer a scoped paid discovery phase | Material dependencies remain unknown and resolving them requires engineering, supplier coordination, or a defined investigation | Deliverables, exclusions, client inputs, commercial terms, and review point |
| Pause or decline | The client cannot authorize access, essential responsibilities remain disputed, or the requested service is outside your delivery model | What must change before reconsideration, or a clear statement that you cannot take the work |
Price and approve paid discovery under your normal commercial process. Keep its deliverable separate from any promise to fix what it finds.
Once the evidence is available, the MSP project scoping guide covers work packages, assumptions, exclusions, and internal review. The technology assessment template organizes findings. Neither needs to be squeezed into the first prospect call.
A fictional handoff: the extra office
A prospect reports 50 users and asks for a monthly support quote. During intake, the account lead learns that a second office is opening, warehouse devices are shared, and a separate supplier owns the business application.
Those are fictional details for this example, not a customer result or a pricing benchmark.
The account lead records the user count as reported and requests a device/site list. The new office becomes a separate transition dependency. The application supplier becomes an evidence owner. Nobody promises that the existing backup arrangement meets the client's recovery expectation before reviewing the restore evidence.
The next deliverable is a bounded assessment, followed by a reviewed service scope and a separately defined transition project if needed. The prospect gets a useful answer about what happens next. Engineering gets questions it can resolve.
A follow-up can be this plain:
"You want support in place before the second office opens. We still need to verify device coverage, application responsibilities, and recovery expectations. Please confirm who can provide those records through our agreed secure channel. We'll review the assessment scope together before committing to service coverage or transition pricing."
Carry the evidence into a reviewed scope
The intake tells the assessment team what to investigate. Keep the original answer beside the verified finding, including any disagreement. A changed device count, an inaccessible tenant, or an unsupported dependency should be visible before it changes the quote.
Scopable's assessment and scoping workflow supports client-linked assessment sections, findings, recommendations, and review before quote work. Connected data depth depends on the systems and permissions available; the MSP still owns the assessment judgment. Keep the prospect intake in your existing process and use the reviewed client evidence to define the work.
If you want to evaluate that handoff on a real client, start Scopable for free.
