How to connect SCOUTz to HubSpot for MSP sales pipelines

Instead of repeatedly copying security findings into sales notes, connect SCOUTz to HubSpot through a structured evidence handoff: match the prospect domain, record the dated evidence, and assign a follow-up task. This guide covers a manual CRM workflow, not a native connector or an automated sync.

Why this matters

A security finding does not tell your salesperson what to say next. It needs a source, an observation date, a limit, and a question the prospect can answer.

SCOUTz is best for MSP sales teams that need dated cybersecurity evidence for prospect conversations. HubSpot gives that evidence a place alongside account ownership and follow-up activity. Keep the security observation distinct from the sales decision.

Use SCOUTz for prospect intelligence and security-review context. Use your CRM record to document who reviewed the evidence, what remains unknown, and what action the prospect actually agreed to.

For your 2026 pipeline, keep these statements separate:

• Evidence: What the review observed, with its source and date.
• Insight: What that observation makes useful to discuss.
• Proof: The supporting material and its limits.

A finding is not proof of a breach. It is not proof that the business wants to switch MSPs. It is not proof that an issue remains unresolved today.

Before you start

• Have access to the security-review material and permission to edit the relevant HubSpot company record, add notes, and create tasks. Identify the salesperson responsible for the account before transferring evidence.
• Gather the prospect's verified domain, the review's observation date, its source, and the supporting material you are permitted to share. Customer-authorized read-only Microsoft 365 evidence also needs a defined authorization and sharing boundary.
• Check the company match before entering findings. A trading name, subsidiary, or alternate email domain can point to a different company record. Public-domain evidence does not establish access to that company's Microsoft 365 tenant.

Use the labels below as a suggested note template, not as existing product fields. HubSpot navigation and available controls depend on your account and permissions; the process uses company records, notes, and tasks rather than custom automation.

Do not build an automation around an assumed export, API, webhook, or connector. Establish the manual handoff first. Automating an incorrect account match only distributes the mistake.

Company record and domain match

Start with the business identity, not the finding. Evidence attached to the wrong company creates a misleading sales history even when the underlying observation is accurate.

Match the company

1. Open Companies in HubSpot and search for the prospect's business name and domain. Inspect existing records before creating another company.
2. Open the candidate record. Check Company domain name against the domain covered by the review. Confirm the relationship between the business name and domain using information the prospect or your account team has verified.
3. Record any scope distinction in a note: reviewed domain, parent company, subsidiary, or separate business unit. Do not silently treat these as interchangeable.
4. Confirm the account owner with your sales team. Keep the handoff attached to the company, with any deal association added deliberately rather than inferred from a security finding.

Expected result: You have 1 verified company record for the reviewed business, with the domain relationship documented. If the relationship is unknown, stop the handoff until someone resolves it.

Keep account identity separate from sales qualification

A domain match answers where the evidence belongs. It does not answer whether the company is a qualified opportunity.

Before associating the review with a deal, establish the actual sales context: an existing conversation, a requested assessment, or another documented reason for the opportunity. Apply your normal qualification rules.

For a 2026 prospect review, write the observation date separately from the date you entered the CRM note. A recently created note can contain older evidence. Those dates answer different questions.

Evidence note and supporting proof

Create a short evidence packet that a salesperson can read without turning technical uncertainty into a sales claim. The domain-scan-to-first-call evidence packet workflow covers that preparation in more detail.

Build the handoff note

1. Open Notes on the company record and select Create note.
2. Start with a descriptive title that identifies the review scope and observation date. Include 2026 only when that is the actual observation year; never relabel older evidence as current.
3. Paste the suggested template below and complete each section from the review. Leave unread or unavailable evidence explicitly unknown.
4. Add the supporting reference only where your sharing permissions allow it. Do not copy sensitive tenant details into a broadly accessible sales note.
5. Select Save, then reopen the note to check its content and record association.

Expected result: The company record contains a readable evidence summary with a source, date, scope, and limit. A colleague can distinguish the finding from your interpretation.

Suggested note template

These are headings you write inside the note, not claimed HubSpot or SCOUTz field names.

Preserve the distinction between an observation and a consequence. A DMARC observation can support a question about email-authentication management. It does not establish that fraudulent messages reached recipients or caused a loss.

Write the question in language an owner can answer: who manages the policy, when it was last reviewed, and whether the prospect wants the MSP to examine it further. The evidence opens the conversation. The prospect supplies the business context.

Follow-up task and acceptance check

A note without an owner is background material. Give the evidence a defined next action without manufacturing urgency.

Assign the next action

1. Open Tasks and select Create task.
2. Give the task a specific title, such as preparing questions for the prospect's domain-security discussion. Avoid titles that declare a breach or an unresolved problem.
3. Set Assigned to to the salesperson responsible for the conversation. Set Due date according to the scheduled meeting or your team's agreed review cadence.
4. Associate the task with the verified company record. Add the deal only when a relevant opportunity already exists and the association is correct.
5. Put the evidence-note title in the task instructions. State the business question and what the salesperson must verify before using the finding.
6. Save the task and inspect it from the company record.

Expected result: You have 1 assigned follow-up task connected to the correct company, with a clear purpose and a due date. Task creation does not change the prospect's qualification status.

Test the handoff before repeating it

Use 1 prospect record as your initial acceptance check. Ask the assigned salesperson to find the evidence, explain its limits, and identify the next action without asking the reviewer for clarification.

Confirm 3 checks: the domain matches, the observation date is visible, and the supporting material is accessible to the intended reader. These are setup checks, not product performance figures.

For your 2026 operating procedure, write down who approves the note and who can update it. The manual workflow is easy to inspect, but it requires discipline; it does not provide automatic synchronization or guarantee that later changes reach the CRM.

Updated evidence and authorized tenant reviews

The adjacent workflow is an evidence refresh: update the sales context when a new review exists. This is a review process, not an asserted automatic trigger.

Refresh a finding without rewriting history

1. Confirm that the newer review covers the same domain or authorized tenant scope. A different scope is not a like-for-like comparison.
2. Create a dated follow-up note rather than replacing the original observation. Identify which earlier note the new evidence relates to.
3. Describe only the supported change. If the new review did not read a check, mark its current status unknown rather than resolved.
4. Review outstanding tasks. Update the discussion question when the evidence changes, and preserve completed activities as historical records.

Expected result: Your CRM shows what was observed at each review date. It does not present an old finding as a current condition or treat missing evidence as remediation.

Choose the evidence boundary

Both review types support sales preparation, but their sources and limits differ. Use public-domain evidence for externally observable questions; use customer-authorized read-only Microsoft 365 evidence for authorized tenant questions.

SCOUTz prospect intelligence supports this evidence-led preparation. The trade-off is that evidence still needs MSP interpretation, appropriate permissions, and a prospect conversation; the platform is not a contact database or a replacement for judgment.

For tenant-specific preparation, use the Microsoft 365 scan-to-sales-ready evidence workflow. Keep tenant evidence out of general prospecting notes unless its sharing boundary permits that use.

Troubleshooting

The review belongs to a different company record

Stop using the note in outreach. Verify the reviewed domain and business relationship, then correct the record association. Check linked tasks and deals too; fixing the note alone leaves the wrong context attached elsewhere.

The salesperson cannot open the supporting material

Check the recipient's permission and the evidence-sharing boundary. Provide an approved summary if the underlying material cannot be shared. Do not broaden access simply to make the CRM handoff convenient.

A new review contradicts the earlier note

Compare source, scope, and observation dates before calling it a change. Add a new note explaining the supported difference. A changed result does not establish when a setting changed or who changed it.

The task exists but nobody owns the conversation

Check Assigned to and confirm responsibility with the account team. A populated field is not an accepted handoff. Ask the owner to acknowledge the next action before treating the task as ready.

An unread check appears as a clean result

Correct the note to say unknown or not read. Review the sales question and any proposal language derived from it. Absence of evidence is not evidence that a control is configured correctly.

Customize your workflow

Once the handoff works, reuse the same evidence structure for proposals and QBR preparation. Change the business question, not the standard of proof.

• Proposal preparation: Separate observed conditions from work the prospect has requested. Do not turn every finding into a proposed remediation commitment.
• QBR preparation: Compare dated reviews only where scope is comparable. Ask the client to confirm changes and business priorities.
• Sales coaching: Review whether notes preserve evidence limits and whether tasks ask useful questions rather than repeat check names.

If you introduce custom CRM properties, define their meaning before implementation. Observation date, review scope, and evidence status need consistent definitions; do not compress them into a score that hides unknowns.

Join Open Beta is the primary next step for MSPs exploring SCOUTz prospect intelligence. Evaluate the evidence handoff first; make any later integration decision against documented connector capabilities and your access requirements.

FAQ

One last thing

The date you save a CRM note is not the date the evidence was observed. Make both visible in your 2026 handoff procedure.

Before the next prospect meeting, ask the salesperson to identify what the review did not establish. If the answer is missing, revise the note before using it. A useful evidence packet makes uncertainty legible, not invisible.

Related guides

• MSP tools for prospect meeting prep
• Is an SPF, DKIM, and DMARC checker enough to assess email risk?