Domain scorecard
Sample domain · public signals only · no internal access
Passive discovery uses legitimate public evidence to prepare the first conversation without changing the prospect environment. An authorized cloud review uses customer-approved, read-only access to evaluate supported internal configuration and metadata.
I owned MSPs. If one of my sellers had asked a new prospect for Global Admin before earning a second meeting, we would have had a short conversation afterward. That permission screen is not a business card.
My book opens with Sarah, a manufacturer whose production floor went silent one Monday after a "routine" weekend update.
"'This happens every damn time,' Sarah told me later, her voice tight with frustration that had been building for years. 'We pay them a fortune, and all they do is fix what broke yesterday.' ... They're paying significant money for IT support, and they have no idea if they're getting value or getting taken."
That last sentence is why SCOUTz starts outside the tenant. Public evidence answers Sarah's question before anyone asks for a single credential: here is what is observable, here is what it means, here is what we cannot know from out here. Permission gets requested only when the conversation has earned a reason for it. Value first, keys later. Sarah deserved that order, and so does every prospect.
From The 3AM Test by Steve Copeland.
An MSP preparing for a first conversation can begin with the public facts already visible from the sidewalk. Global Admin, an endpoint agent, network credentials, RMM access, and the incumbent's documentation belong behind a clear purpose and customer approval.
SCOUTz begins in a smaller, more honest place: what can we legitimately observe now, what does that evidence support, and where does the answer stop?
What can an MSP review without client access?
Public company context and bounded outside-in evidence can help an MSP understand the organization, domain, DNS, email authentication, certificate posture, web protections, public infrastructure, and other supported external signals. That is enough to arrive with useful context and sharper questions.
It is not enough to establish internal Conditional Access coverage, exact OAuth permissions, privileged accounts, license assignment, managed-device state, internal sharing, backup health, or runtime AI use. Those answers live behind a different boundary.
That limitation is not a product embarrassment. It is the line where the relationship should take over.
Do MSP pre-sales reviews need an agent?
Not for the outside-in question SCOUTz is answering. An installed agent can be valuable when continuous endpoint management, deep device evidence, or active monitoring is the job. The first handshake usually is not that job.
The sequence should be public evidence, useful questions, trust, authorization, and then the deeper source appropriate to the question. An agentless first look reduces friction because the MSP does not have to ask a prospect to install software merely to decide whether a conversation is worthwhile.
Passive does not mean probe everything. Public availability is not a permission slip for aggressive reconnaissance, unlimited collection, or a claim of zero risk. Scope, source policy, provider limits, rate limits, and the product's own boundaries still matter.
Why does a Microsoft 365 review require permission?
Because the question changed.
Checking whether a domain publishes DMARC requires public DNS. Reviewing which enterprise applications hold tenant-wide permissions requires authorized Microsoft application and permission evidence. Reviewing identity, licensing, sharing, security configuration, or managed-device metadata requires supported access to those sources.
SCOUTz asks the customer to approve that next layer, explains the purpose, uses read-only collection, and keeps permission-, license-, provider-, and readability limits visible. Authorization improves the evidence available. It does not make the entire environment visible, and it does not convert every result into verified fact.
Why use a read-only cloud review?
Read-only access can still reveal deep relationships across configuration, permissions, consent, ownership, coverage, history, and supported activity. It lets the MSP validate conditions without giving the review engine permission to make production changes.
SCOUTz explains and organizes the work. The MSP validates the environment, recommends the action, and uses the established operational stack to execute it. SCOUTz returns only where a supported source can verify the changed condition.
That is the progressive trust model: observe what is appropriate now, say what remains unknown, earn permission for the next source, and never ask for more access than the question requires.