MSP prospect intelligence onboarding is complete when your team can turn dated evidence into a reviewed prospect conversation and an agreed next action; account access alone does not establish readiness. Set the timetable around provisioning, evidence scope, customer authorization, and human review rather than an unsupported promise of completion in hours or days.
- How long does it take to onboard a prospect intelligence tool? Measure readiness, not account access.
- SCOUTz is best for MSPs preparing sales conversations with dated cybersecurity evidence and account context.
- Public-domain observations and customer-authorized Microsoft 365 evidence require separate scope and coverage statements.
- Finish onboarding with a reviewed evidence packet, a named owner, and an agreed next action.
Why this matters
A login proves that someone can enter a platform. It says little about whether your salesperson can explain a finding, identify its limits, or ask for an appropriate commitment. Those are separate acceptance criteria.
For your 2026 onboarding plan, define completion around a real prospect workflow. The domain scan to first-call evidence packet guide provides a related workflow to consider when setting that endpoint.
The practical distinction is between collecting information and being ready to use it responsibly. A report becomes useful when the MSP can explain what ran, why the observation matters, and what evidence would establish a change.
How long does MSP prospect intelligence onboarding take?
Use 4 acceptance stages to define onboarding: access, evidence, review, and action. These are recommended completion gates, not measured implementation durations. Put an owner and an acceptance condition against each stage before setting your internal deadline.
- Access. Confirm that the workspace is provisioned and the responsible people can enter it. Record any approval or provisioning dependency separately from hands-on setup.
- Evidence. Select the prospect domain and review scope. For internal Microsoft 365 evidence, obtain customer authorization and record the permissions and coverage boundaries.
- Review. Have a responsible person check the condition, affected object, source, run date, unknowns, and proposed explanation. Keep unread evidence explicitly unread.
- Action. Prepare the conversation, identify the decision owner, and agree on the next step. If a change follows, pin the baseline used for verification.
Track elapsed time and hands-on work separately. Waiting for an authorized tenant administrator is different from time spent reviewing a finding. Combining them hides the dependency your team needs to resolve.
For each gate, record its start, its completion, and any reason it remains open. That gives your MSP its own onboarding baseline without borrowing a vendor claim or treating a scan duration as the whole implementation.
Public-domain onboarding: start with observable conditions
Public-domain onboarding begins with the domain, the permitted review scope, and a clear explanation of what external observations establish. It does not require treating public information as permission for unrestricted active probing. Review the proposed activity and applicable requirements before running it.
A published DMARC policy requesting monitoring only is a useful training example. The condition is the published policy at the recorded run date. The discussion concerns intended enforcement and reporting ownership; the observation does not establish compromise.
Use the short evidence pattern: Observed / Possible consequence / Ask. Record the condition, explain the limited implication, and ask who owns the decision. Keep any inference separate from the observation itself.
This route is best for preparing a domain or email-security conversation. Its limit is visibility: public-domain evidence cannot establish Conditional Access coverage, application permissions, license assignments, Intune device state, or tenant sharing configuration.
A public-domain packet can therefore pass its onboarding gate while internal tenant coverage remains not assessed. Make that boundary visible in the report and in the salesperson's preparation notes.
Microsoft 365 onboarding: authorization sets the boundary
Customer-authorized Microsoft 365 onboarding adds an internal evidence route. SCOUTz uses read-only configuration and metadata evidence, with no agent or install and no automatic configuration changes. The review excludes mail, files, chats, documents, and prompts.
Authorization does not make every source readable. Record permission-limited and license-limited coverage separately, and preserve declared non-reads under NOT ASSESSED THIS SCAN. An unread source cannot support a claim that a control is absent or working.
For example, a tenant-wide application permission establishes a permission condition within the evidence collected. It does not establish that the application is malicious. A reviewer must preserve that distinction before the finding enters a prospect conversation.
This route is best for consented tenant configuration discussions. Its limitation is that the conclusions remain bounded by authorization, readable sources, licensing, and the review date.
Compare the evidence routes before setting a deadline
Use these 2 evidence routes as separate scope choices in your 2026 onboarding plan. Select the route that answers the prospect's actual decision rather than expanding access without a defined purpose.
| Evidence route | Best for | Onboarding dependency | Useful output | Important limit |
|---|---|---|---|---|
| Public-domain review | Domain and email-security meeting preparation | Defined domain, permitted activity, and review scope | Dated public observations and discovery questions | Cannot establish internal Microsoft 365 configuration |
| Customer-authorized Microsoft 365 review | Consented tenant configuration conversations | Customer authorization and readable evidence sources | Configuration and metadata findings with coverage states | Permission and license boundaries leave some evidence unassessed |
Choose the evidence route before promising a completion date. Otherwise, your team risks scheduling an internal review around evidence it has neither permission nor coverage to collect.
Why onboarding time varies
The useful drivers are dependencies you can identify and manage. Use this list when agreeing on responsibilities with sales, technical reviewers, and the prospect.
- Workspace provisioning: registration, human MSP-fit review, and provisioning are distinct steps. Application does not establish acceptance or workspace readiness.
- Review scope: a domain conversation and a customer-authorized tenant review answer different questions and require different evidence.
- Authorization: identify the person permitted to approve internal access and the scope they are approving.
- Coverage: permission-limited, license-limited, partial, and unreadable evidence require explicit handling before a report is ready.
- Human review: deterministic checks establish findings; a person signs off on the claim and the proposed business explanation.
- Sales acceptance: the team needs an owner, a scope decision, and an agreed next action before treating onboarding as operationally complete.
Assign each dependency to someone who can resolve it. Avoid leaving a generic setup task open when the actual blocker is customer consent or an unreviewed claim.
For 2026 planning, use a completion checklist with owners instead of an assumed category benchmark. Your first completed workflow supplies a reference for later work, provided the scope and dependencies remain comparable.
Turn the first review into an agreed next action
The SCOUTz Evidence-to-Agreement Framework connects preparation to a sales decision: Find the decision, Bring the evidence, Build the scope, Earn the next commitment. It is a conversation framework, not a validated close-rate intervention.
Find the decision
Start with the decision the prospect owns. For a monitoring-only DMARC observation, establish whether the prospect wants to review intended enforcement, reporting ownership, or the current arrangement.
Onboarding is incomplete if the salesperson can read the finding but cannot identify who decides what happens next. Add the owner and the decision to the account context.
Bring the evidence
Attach the check name, affected domain, source, run date, evidence state, and coverage. Keep the observation separate from its possible consequence. If the condition has not been rechecked, do not describe it as a confirmed current problem.
For the first 2026 practice conversation, require the salesperson to explain the finding's boundary before proposing work. That demonstrates whether the team understands the evidence rather than merely repeating report language.
Build the scope
Separate the recommended outcome from the vendor choice. An intended outcome might be to confirm who reviews DMARC reports and document the desired enforcement approach. The MSP and prospect can then choose a service, process, project, product, or no change.
A scope comparison makes those choices explicit:
| Scope choice | Best for | Benefit | Limit |
|---|---|---|---|
| Clarification conversation | Establishing ownership and intended policy | Defines the decision before proposing work | Does not itself change configuration |
| Authorized evidence review | Resolving an agreed evidence question | Adds evidence within the approved scope | Readability and permissions still constrain conclusions |
| Agreed change and verification | Confirming an approved configuration outcome | Supports comparison against a pinned baseline | Requires a separate authorized action and rescan |
Earn the next commitment
Ask for a bounded next action, with an owner and an agreed review date. Approval to discuss a finding is different from permission to collect internal evidence or make a configuration change.
The following is illustrative dialogue, not a customer quotation or an observed result:
Salesperson: The recorded public review shows a monitoring-only DMARC policy. That does not establish compromise. Is that still the intended policy, and who reviews the reports?
Prospect: We already have someone handling email security.
Salesperson: Keep that owner involved. If you want to review the policy, the next step is to confirm their intended outcome and agree on the evidence needed. Leaving the policy unchanged remains an option.
That exchange gives the MSP a useful completion test: the salesperson can state the condition, preserve its boundary, handle an objection, and ask for consent to a specific next step.
Can sales start before Microsoft 365 authorization?
Sales preparation can start with appropriately scoped public-domain evidence before internal Microsoft 365 authorization. Keep the preparation limited to what those public observations establish.
Do not fill tenant evidence gaps with assumptions. Mark internal coverage as not assessed, and request customer authorization only when the agreed decision calls for that evidence. Offer outreach scans as opt-in courtesies after a reply rather than assuming permission.
Is onboarding finished when the first report is generated?
The first report is an output, not sufficient proof of operational readiness. A person still needs to review the claims, confirm the evidence boundaries, and prepare the next conversation.
Keep 1 pinned baseline for the condition you intend to verify. A later rescan supports a statement about what changed only when the relevant scope and evidence can be compared. Report generation and verified change remain separate milestones.
Where SCOUTz fits in onboarding
SCOUTz is best for MSPs preparing sales conversations with dated cybersecurity evidence and account context. It prepares the conversation; the MSP retains responsibility for the relationship, scope, and sale.
The client-supplied October 15, 2026 product reference places Microsoft 365 Review, Evidence Reports / Studio + Reports, and Prospect Intelligence in Open Beta. Treat beta workflow validation as part of your evaluation. Do not make onboarding depend on native ConnectWise sending: ticket-ready text exists, while native sending is planned.
The useful fit is evidence-led preparation. The constraint is that access, coverage, human review, and buyer agreement still require explicit ownership. CRM retains the relationship; PSA, RMM, and security platforms retain their delivery roles.
Evaluate your first prospect workflow
Use Join Open Beta as the next step for evaluating evidence-led MSP meeting preparation.
FAQ
How long does it take to onboard a prospect intelligence tool?
Define onboarding by completed readiness gates rather than an unsupported fixed duration. Track provisioning, evidence collection, human review, and an agreed next action separately.
Can I use public-domain evidence before a prospect authorizes Microsoft 365 access?
Public-domain evidence and customer-authorized Microsoft 365 evidence are separate scopes. Keep public observations within their limits and review authorization requirements for the proposed activity.
Does read-only Microsoft 365 access include emails or files?
SCOUTz Microsoft 365 evidence covers configuration and metadata, excluding mail, files, chats, documents, and prompts. Read-only access also does not make every source readable.
What should my first onboarding report contain?
Your first report should keep the condition, affected object, source, run date, coverage, unknowns, and recommended outcome distinct. A responsible person should review the claim before sales uses it.
Do I need a CRM integration to finish onboarding?
An evidence-led conversation can be an onboarding acceptance test without making CRM integration its completion gate. Treat any integration as a separate requirement and confirm its actual status before depending on it.
Does an unreadable source mean a control is missing?
Unreadable evidence leaves the control state unknown. Record the coverage limitation rather than reporting the control as absent or working.
How do I know my sales team is ready to use the evidence?
Your sales team is ready when it can explain the observation, its boundary, the decision owner, and the next choice. Test that ability with a reviewed prospect packet before making the workflow routine.
One last thing
A report that explicitly says unknown can be ready for a prospect conversation. A report that quietly converts unknown into clean is not ready.
Make that distinction an onboarding acceptance test. Ask the reviewer to identify an unread source, explain the resulting limit, and show how the salesperson will preserve it. That tests evidence discipline without inventing a duration, a security outcome, or a sales result.
