Cold domain scan to signed MSP contract: complete 2026 workflow

Instead of rebuilding prospect research before every meeting, use a cold domain scan to signed MSP contract workflow that carries dated evidence through outreach, discovery, an authorized review, and a scoped agreement. Use SCOUTz for prospect intelligence and security reviews; keep qualification, recommendations, and contract decisions with your MSP.

Why this matters

A domain finding answers a narrow technical question. It does not establish who controls the configuration, whether an exception is intentional, or whether the prospect wants a different provider. Treating that finding as a sales conclusion puts your credibility at risk before discovery starts.

SCOUTz is best for MSPs that need dated prospect intelligence to prepare evidence-led sales conversations. Its role is evidence and preparation. It is not a contact database or a replacement for MSP judgment.

For your 2026 pipeline, separate the chain into evidence, insight, and proof:

• Evidence: What a source actually returned, with its observation date and collection limits.
• Insight: Why that observation deserves a business question.
• Proof: What an authorized reviewer or customer confirms, and what remains unknown.

A finding is not a reason to demand a meeting. A relevant consequence, stated within the evidence limits, is a reason to ask a question. A signature comes only after the customer agrees to the work and terms.

Before you start

• Prepare the materials: Gather the prospect's confirmed domain, access to your chosen public-domain review method, a prospect record, and your MSP's proposal and agreement templates. Use 1 domain per evidence record; relate additional domains rather than blending their findings.
• Prepare the authorization: Identify the customer representative who can approve a Microsoft 365 review. Obtain documented permission before tenant access, and use a customer-authorized read-only collection method with the required permissions.
• Gate the hidden dependency: A public domain does not establish tenant ownership or authorize tenant access. Confirm the relevant Microsoft 365 tenant and access scope before scheduling the review; an unread check stays unknown, not clean.

The field labels below belong to a record you create. They are not instructions for a particular software interface. Keep the same labels across your research notes, discovery brief, and proposal evidence appendix so observations do not change meaning between stages.

Prospect record and public-domain evidence

Start with a prospect record, not a pitch. Your first configuration unit establishes what you examined and prevents a public observation from becoming a claim about private systems.

1. Create a record with these fields: Domain, Source, Observed at, Check, Observation, Collection limit, Business question, and Next action. Enter the actual observation timestamp, including time zone, rather than the date you wrote the sales email.
2. Confirm the domain belongs to the intended organization. Record how you established that relationship. If the relationship is unclear, stop outreach based on the finding until you resolve it.
3. Review the public-domain evidence available to you. For email-security work, distinguish published SPF and DMARC records from conclusions about message handling. Record the queried name and the response rather than only a pass/fail label.
4. Preserve the result and its source. Keep an export or observation record that another practitioner can inspect. If collection failed, write that failure into Collection limit instead of substituting a favorable status.
5. Write a bounded Business question. Ask who owns the policy, whether the observed configuration is intentional, and what outcome the organization expects. Do not infer a breach, an unresolved incident, or buying intent.

Expected result: You have a dated, inspectable observation and a discovery question. You do not yet have a confirmed customer problem.

Keep the evidence lanes separate

Use 2 evidence lanes in your 2026 workflow. Each serves a different purpose, and neither replaces customer context.

For example, a published DMARC policy is evidence about that DNS record. It does not, by itself, prove every legitimate sender is aligned or show how every receiving system treats messages. The useful next move is a question about email-security ownership and intended policy, not a declaration that the prospect is compromised.

Discovery brief and authorized review

The next configuration unit turns a technical observation into a conversation the prospect can correct. Build the brief before writing outreach so your message has a bounded purpose.

1. Create a discovery brief with Evidence, Insight, Question, Customer context, and Review permission. Copy the observation and collection date without strengthening its wording.
2. Write the insight as a conditional consequence tied to the observed configuration. For a DMARC observation, discuss the published policy's role in domain-based email authentication. Do not attach a speculative loss figure or claim an attack occurred.
3. Draft outreach that states what you observed, when you observed it, and what you want to understand. Ask whether the prospect wants to discuss the configuration; do not imply that a scan created an obligation to respond.
4. During discovery, record the customer's explanation separately from the technical result. An intentional exception, a migration, or a different responsible provider changes the next question. It does not rewrite the original observation.
5. If tenant evidence would answer an agreed question, document permission, tenant identity, review scope, access requirements, and evidence recipients before collecting Microsoft 365 data. Keep assessment access separate from permission to make changes.
6. Review the authorized results against the approved scope. Mark unavailable, excluded, or failed checks explicitly. Ask the customer or authorized practitioner to confirm operational context before describing work as necessary.

Expected result: Your discovery brief distinguishes observed facts, customer statements, and open questions. Any tenant review has a documented permission boundary.

A useful 2026 brief also names the decision under discussion. That decision might be whether to investigate email authentication, validate a tenant control, or commission a scoped assessment. It is not automatically whether to replace the incumbent MSP.

Use SCOUTz prospect intelligence as evidence for that brief, not as proof that the organization is ready to buy. A dated review can support a question. Only the prospect can confirm its priorities and decision process.

Proposal evidence and contract approval

This configuration unit connects evidence to deliverables. Keep the chain visible: source, interpretation, confirmed requirement, proposed work, and acceptance evidence. A proposal that skips those links asks the customer to trust a conclusion they cannot inspect.

1. Create a proposal evidence appendix using Source, Observed at, Confirmed requirement, Proposed work, Exclusions, Customer dependency, and Acceptance evidence. Keep the original collection date visible beside every cited observation.
2. Classify each supporting item using 3 proof states: Observed, Customer-confirmed, and Unknown. Customer confirmation adds context; it does not turn an unperformed technical check into a verified result.
3. Write the deliverable in terms of work your MSP will perform. Separate assessment, configuration changes, validation, and ongoing management. Read-only review authorization does not authorize remediation.
4. Define acceptance evidence for each deliverable. Specify the artifact or verification that will demonstrate completion, along with who reviews it. Avoid a blanket promise to make the environment secure.
5. Record exclusions and dependencies before presenting the agreement. Include access, customer approvals, affected systems, and third-party coordination where relevant. Keep unresolved assumptions visible rather than burying them in the proposed outcome.
6. Have the appropriate customer representative review the scope and agreement through your normal approval process. Obtain the required signatures before treating the work as contracted. Record the approved version and signature status in the prospect record.

Expected result: The signed agreement describes authorized work, boundaries, and acceptance evidence. It does not promise a particular sales outcome or certify the customer's entire environment.

For a 2026 proposal, confirm whether cited evidence still represents the configuration being discussed. Recheck material observations when necessary and preserve the earlier record. Evidence collected before a customer change belongs in the history, not in an unqualified statement about current conditions.

Handoff record and delivery ownership

A signature changes the commercial status. It does not resolve access questions, approve every change, or complete the work. Configure the handoff so delivery receives the same boundaries sales agreed with the customer.

1. Assemble the signed scope, evidence appendix, customer explanations, exclusions, and open questions into the handoff record. Separate prospect research from evidence collected under customer authorization.
2. Assign an owner for each deliverable and dependency. Record who obtains access, who approves changes, and who accepts completion evidence. Do not assume the sales contact holds every authority.
3. Confirm the delivery team understands the collection limits. Carry unread checks into the assessment plan rather than presenting them as completed checks.
4. Establish the change-approval path before remediation begins. Keep any new request outside the signed scope until the customer approves the appropriate scope change.
5. Return completion evidence against the acceptance criteria. Preserve exceptions and deferred work so a later review can distinguish completed work from agreed follow-up.

Expected result: Delivery receives an actionable agreement and an honest evidence history. The customer can see what was examined, what was agreed, and what remains open.

The workflow's stopping rule matters: if the prospect declines further review or does not approve the proposal, record that decision without inventing a technical reason. A scan is not a mandate to continue selling.

Refresh the workflow when evidence changes

Use the same evidence chain for a customer-authorized follow-up or QBR. The difference is context: an existing customer has agreed services and prior evidence, while a cold prospect has neither.

• Capture a new observation under the applicable authorization and source limits.
• Compare the same check and scope where possible. Label scope changes before describing a difference as improvement or deterioration.
• Ask the customer to confirm whether the change was intentional and whether it affects an agreed objective.
• Propose follow-up work only when it falls within the service agreement or receives separate approval.

Best for: QBRs and follow-up reviews that need a traceable connection between past evidence and present decisions. The benefit is continuity; the limitation is that unlike-for-like collections do not support a clean trend claim.

In a 2026 QBR, show the previous observation date alongside the new one. A changed DNS response is a changed observation, not proof that your MSP caused the change or prevented an incident.

Troubleshooting

The domain belongs to a different entity

Pause the prospect-specific conclusion. Confirm the domain relationship and responsible organization, then attach the evidence to the correct record. Similar names are not ownership proof.

Public evidence conflicts with the customer's explanation

Keep both statements with their sources. Recheck the specific record and ask about timing, domain selection, or a recent change. Do not erase evidence to fit the account, or dismiss customer context to preserve the pitch.

Microsoft 365 collection cannot read a check

Record the result as unknown and identify the access or collection error. Ask the authorized administrator to review the approved permissions. Do not broaden access without approval or label the control absent because it was unread.

The proposal contains an unverified requirement

Return the item to discovery. Separate the observation from the inference and obtain the context needed to scope work. If the customer wants an assessment to resolve the uncertainty, describe assessment work rather than a confirmed defect.

Sales and delivery interpret the scope differently

Resolve the disagreement against the approved agreement and acceptance criteria before starting the disputed work. Document the clarification with the customer; do not silently expand the deliverable.

Customize your workflow

Choose the discovery question before adding more checks. Email-security ownership, tenant access, and customer-approved validation need different evidence. Collecting more does not excuse collecting without a purpose or permission.

Make Join Open Beta your primary next step with SCOUTz. Keep the evaluation focused on whether dated evidence supports your MSP's preparation and review process, not on an assumed increase in signed contracts.

FAQ

One last thing

An unknown check belongs in the handoff, not just in the research notes. It can change what delivery must assess before making a recommendation. Keeping it visible protects the boundary between work sold, work performed, and work still needed.

Related guides

• 7 best MSP prospecting tools