Choose a source
Start with the source that has the clearest evidence value for the tenant, such as RMM endpoint health, PSA tickets, MDR investigations, or billing context.
User Guide
Run OPTIC with source-backed evidence.
OPTIC helps MSP and operations teams connect telemetry, tickets, security findings, billing context, and imported evidence into reviewable workflows.
Guide NavigationBrowse sectionsOpen menu
First Run
Start with the tenant and the source.
Complete setup
Add the visible connection fields, then confirm the tenant-scoped credential reference is available before running validation.
Review readiness
Use readiness actions to resolve missing fields, missing credentials, provider validation failures, or manual-import-only states.
Confirm evidence
A successful connection is only useful when OPTIC imports source-backed evidence that supports triage, billing review, or client reporting.
Roles
Use the same evidence from different seats.
Each role sees the same source-backed truth, but each starts from a different operational question.
Prepare tenants, users, API keys, source records, and approval guardrails.
Open Settings, confirm tenant access, then create or review the saved source connection.
Review readiness actions, imported evidence, source lineage, and related findings.
Open Data Sources, select the tenant source, then resolve the highest-priority readiness action.
Understand what evidence supports a finding, billing review, or client-reporting note.
Open the evidence package or report view and inspect source, severity, timestamps, and related evidence.
Onboarding Checklist
Get to the first trustworthy review.
A pilot should prove source value before broad rollout. Work through a small tenant, one useful source, and one reviewed evidence package first.
- Create or confirm the tenant and who can administer it.
- Choose one source that can prove real service activity.
- Save the visible connection fields and tenant credential reference.
- Run readiness and resolve every required operator action.
- Import or sync a small evidence set and confirm records are useful.
- Review one evidence package before using findings in a report.
- Confirm approval rules before enabling any write-back workflow.
Workspace Map
Know where to go next.
Most user tasks start in one of three workspaces: operations, connections, or settings. Demo pages show the intended workflow before a live source is connected.
Operations HubReview tenant coverage, operational evidence, client reporting, and MSP workflow demos.Data SourcesAdd sources, inspect readiness, review sync runs, and open imported evidence.SettingsManage tenants, users, API keys, access requests, and administrative setup.MSP investigation demoWalk through a source-backed endpoint investigation with security and ticketing evidence.Billing demoSee how observed service delivery connects to billing review and client reporting.Spreadsheet intelligence demoImport spreadsheet exports, normalize evidence, and review AI-assisted discrepancy detection.
Demo Paths
Use demos to learn the workflow before connecting live sources.
Each demo is designed around a specific operating question, not a generic product tour.
Learn incident correlationUse the MSP investigation demo to see endpoint, security, ticket, and billing context joined into one review.Learn billing reviewUse the billing demo to see observed service delivery compared with agreement and seat-count context.Learn spreadsheet discrepancy reviewUse spreadsheet intelligence to see asset, finding, and ticket exports normalized into a review queue.Learn operations coverageUse verification views to inspect source coverage, tenant readiness, and evidence gaps before rollout.
Input/Sources
Connect the tools that prove the work.
Start with inputs and sources that show what happened, who handled it, and whether the work should affect reporting or billing review. OPTIC can use direct integrations, manual uploads, spreadsheets, or governed object storage paths such as S3, Azure Blob Storage, and Google Cloud Storage.
Confirms device inventory, patch activity, endpoint state, and operational follow-up.
Adds threat, alert, investigation, and endpoint-security context to operational findings.
Connects service work, customer communication, and technician follow-up to the evidence trail.
Compares observed service delivery with commercial context for billing review and client reporting.
Lets teams validate workflows before a production sync adapter is available.
Lets teams point OPTIC at governed buckets or containers where providers, scripts, or exports already land operational data.
Connection Maturity
Do not confuse a pilot path with production support.
Connection maturity describes how much of the setup, sync, evidence, and operations path has been proven.
The source is valuable, but setup guidance or adapter work is not ready for pilot use.
OPTIC can model setup, mapping, or sample evidence, but production sync is not implied.
Read-only validation or bounded imports are available for design-partner workflow testing.
The source has useful evidence, clear operator actions, and hardening work identified.
The source has setup guidance, credential handling, sync behavior, observability, and review workflows.
Pilot Access
Ask for the least access that proves the workflow.
For a first partner validation, read-only credentials are the right default. OPTIC should prove source mapping, evidence quality, and approval flow before any live write-back permission is granted.
Request source access that can validate credentials and import bounded evidence without remediation, script, remote-control, isolation, or ticket mutation rights.
Confirm imported records include source IDs, observed timestamps, severity, asset or account context, and provider identity before broad rollout.
Ticket creation, endpoint containment, billing changes, and source updates should stay behind tenant policy and approval state.
Dry-run action execution is enough to test evidence-to-ticket preparation before a partner explicitly approves live write-back.
Connection Readiness
What each readiness state means.
Readiness combines saved setup fields, credential availability, provider validation, latest sync history, and imported evidence counts.
Complete the tenant-visible setup fields before retrying validation.
Add tenant-scoped secret material or credential references before live validation or sync.
Check the provider URL, credential scope, API permissions, and provider availability.
Use payload import until the provider has a read-only sync adapter.
Evidence Review
Follow the lineage before the recommendation.
Evidence packages show the source integration, provider, severity, event type, intake path, related sync runs, and ranked correlation candidates.
NewEvidence has been imported and still needs operator review.
ReviewedA person has inspected the evidence and source lineage.
TriagedThe evidence has been connected to a finding, issue, or recommended next step.
SuppressedThe evidence is known noise or not useful for the current workflow.
ArchivedThe evidence is retained for history but removed from active review.
Data Lifecycle
How source evidence becomes a decision.
- CollectOPTIC receives a provider payload, sync result, or manual import.
- NormalizeThe source event becomes a consistent imported evidence record.
- CorrelateRelated evidence is ranked by shared asset, account, signal, severity, and recency.
- ReviewAn operator checks source lineage before accepting a recommendation.
- DecideThe team triages, reports, suppresses, archives, or requests a governed action.
Data Surfaces
Know where each kind of evidence appears.
OPTIC keeps setup state, imported evidence, review packages, and operations summaries separate so users can inspect the right level of detail.
Connection fields, credential presence, validation state, latest sync, evidence summary, and operator actions.
Provider, severity, event type, status, observed time, source identity, and review state.
Lineage, source path, payload hash, related sync runs, and ranked correlation candidates.
Tenant coverage, workflow summaries, service delivery evidence, and report-ready findings.
Contract reconciliation
How coverage gaps and unbilled hosts are calculated
The report compares active contracted quantities with eligible provider observations. It does not assume every endpoint at a contracted site carries every product.
Quantity calculation
Gap is contracted units minus observed eligible endpoints, with a minimum of zero. Unbilled is observed eligible endpoints minus contracted units, also with a minimum of zero.
Included contracts
Only supported, active, in-date contract services with a positive adjusted quantity are included. Repeated snapshots of the same contract service are deduplicated.
Endpoint eligibility
Workstation and server services are compared with their matching device classes. Services without a device-class restriction use all observed endpoints for that provider at the matched site.
Site mapping
Contract site code and account name use exact normalized matching. Unmatched positive contract rows are shown as needing site mapping and do not inflate the gap.
Drill-down behavior
Unbilled values can identify observed machines. A quantity gap links to contract evidence because OPTIC cannot truthfully name the absent machines unless the contract identifies them.
Example
100 contracted SentinelOne units and 87 observed eligible agents produce a gap of 13 and zero unbilled hosts.
Search And Filters
Narrow evidence before drawing conclusions.
Filtering is part of the review process. It helps prevent broad tenant evidence from being mistaken for evidence about one client, endpoint, or incident window.
- Filter imported evidence by provider, severity, status, event type, account, hostname, tag, and time window.
- Use source or integration filters when the review is about one connected tool.
- Use account and hostname filters when checking whether related evidence belongs to the same client or asset.
- Use status filters to separate new evidence from reviewed, triaged, suppressed, or archived records.
- Use observed-time filters for incident timelines and imported-time filters for sync or ingestion troubleshooting.
Reading Output
Use recommendations as review packets.
OPTIC output is designed to focus attention. The final decision still depends on source lineage, tenant policy, and human judgment.
Use it as a summary, then verify the source evidence before acting.
Treat severity as a prioritization signal, not a final business decision.
Start with same-asset and same-account matches before weaker context.
Check whether the action is read-only, approval-gated, or outside current policy.
Use source-backed reporting text only after a person has reviewed lineage and scope.
Review Checklists
Use a checklist before trusting the workflow.
These checks keep pilots disciplined and help teams avoid turning partial evidence into overconfident action.
Connection setup
- Tenant context is correct.
- Visible provider fields are complete.
- Credential reference is present.
- Readiness has no required operator actions.
- Latest sync or import produced useful evidence.
Evidence package
- Source system and provider are visible.
- Observed timestamp matches the incident window.
- Asset, account, user, or service identity is plausible.
- Related evidence is ranked and explainable.
- Status reflects the review outcome.
Billing review
- Observed service delivery is source-backed.
- Agreement or seat-count context is current.
- Revenue impact is framed as review value.
- No invoice change is implied without approval.
- Client-facing language names evidence sources.
Client report
- Confirmed facts are separated from recommendations.
- Sensitive internal details are removed.
- Open questions and unresolved scope issues are named.
- Next steps have an owner.
- The report can be traced back to reviewed evidence.
Status Labels
Read badges as prompts for review.
Status labels should tell operators what to inspect next. They are not a substitute for source evidence.
Setup checks pass, but operators should still confirm useful evidence exists.
A required field, credential, provider validation, sync run, or scope issue needs review.
Use payload import or sample evidence until read-only sync is available.
The provider was reachable, but scope or filters may not be producing value.
A governed action cannot proceed until a permitted reviewer approves it.
Evidence Quality
Judge the strength of the link, not just the count.
More records are not automatically better. Strong evidence is specific, scoped, and easy to explain.
Multiple source systems agree on the same asset, account, user, timestamp window, or ticket context.
One reliable source supports the claim, but related evidence is limited or still being reviewed.
The match depends mostly on tags, event type, or broad account context rather than a specific asset or identity.
The source is reachable but missing scope, filters, credentials, or mapped fields needed for review.
Data Handling
Keep the source trail without over-collecting.
OPTIC should preserve enough context to review a claim while avoiding unnecessary secret or raw payload exposure.
Keep provider, integration name, source URL, payload hash, observed time, and import path visible during review.
Prefer normalized evidence and hashes over retaining raw provider payloads unless a workflow explicitly needs the raw artifact.
Treat hostnames, endpoint IDs, account IDs, user names, and service names as matching keys that still require scope review.
Evidence package reads, sync runs, and governed actions should stay traceable to the tenant and actor.
Common Workflows
Where OPTIC fits in daily operations.
Operations triage
Group related signals by service, endpoint, account, user, or event type, then review the strongest same-asset and same-account evidence first.
Billing review
Compare observed service delivery against billing context without automatically changing invoices or agreements.
Client reporting
Turn source-backed evidence into a narrative that shows what happened, what was reviewed, and what still needs a human decision.
Report Handoff
Turn evidence into client-safe language.
When an OPTIC review becomes a ticket note, client report, or billing review packet, keep the evidence and the decision boundary visible.
- Name the source systems used for each claim.
- Include the asset, account, user, or service identity used for matching.
- Separate confirmed evidence from recommended next steps.
- Call out billing review as a human decision, not an automatic invoice change.
- Keep unresolved readiness or sync scope issues visible in the handoff.
Troubleshooting
Resolve the common setup stalls.
Review provider scope, filters, lookback window, and whether the adapter supports sync or manual payload import.
Confirm the tenant credential reference exists on the server side. Do not paste raw provider secrets into visible setup fields.
Check whether hostnames, endpoint IDs, account IDs, tags, and normalized identity fields are mapped consistently.
Review the tenant action policy, approval role, maximum risk, and whether the action still needs a human decision.
Support Packet
Bring the right context when asking for help.
A useful support request should include enough tenant, source, sync, and evidence context for another person to reproduce the review path.
- Tenant name or tenant ID being reviewed.
- Source integration name and provider.
- Readiness status and any visible operator action labels.
- Latest sync status, imported count, and time window.
- Imported event ID or evidence package link when the question is about one record.
- Expected outcome: setup fix, evidence review, billing review, client report, or governed action.
Safety Boundary
Human approval stays in the loop.
- OPTIC stores connection records and credential references, not raw long-lived provider secrets.
- Read-only sync stays separate from write-back actions.
- Manual approval is required for governed actions unless a tenant policy explicitly allows a stronger mode.
- Evidence packages preserve source lineage so operators can see where each claim came from.
- A source that validates but imports zero records should be treated as a scope or filter review.
Current Boundaries
Know what OPTIC is not doing for you.
OPTIC links and explains evidence from connected systems. The PSA, RMM, MDR, billing, or identity platform remains the system of record.
Recommendations should not become write-back actions unless tenant policy and approval state explicitly allow it.
A finding is only as strong as the provider scope, filters, timestamps, and identity mapping that produced it.
Escalation
Route the decision to the right owner.
- Escalate to a platform admin when tenant access, API keys, or credential references are missing.
- Escalate to the source system owner when provider validation fails or evidence scope looks wrong.
- Escalate to a billing owner when observed service delivery conflicts with agreement or seat-count context.
- Escalate to a security owner before acting on high-risk endpoint isolation, containment, or account-control recommendations.
Pilot Success
What good looks like.
A successful pilot should prove that OPTIC makes evidence easier to review, not merely that a source can connect.
- At least one connected or imported source produces useful evidence.
- Operators can explain why evidence is related without opening the source tool first.
- A report or billing review packet can name the source systems behind each claim.
- Required operator actions are clear when setup is incomplete.
- No write-back or billing change happens without the expected policy and approval state.
FAQ
Short answers for common concerns.
Does OPTIC replace our PSA, RMM, MDR, or billing platform?
No. OPTIC preserves source identity and links evidence across tools so operators can review the full story without replacing the systems of record.
Can OPTIC change tickets, isolate endpoints, or update billing automatically?
Not by default. Write-back actions stay behind tenant policies and human approval unless a tenant explicitly enables a stronger mode.
Why does a successful sync still need review?
A sync can reach the provider and still import zero useful records. That usually means the provider scope, filters, or lookback window needs adjustment.
What should users check before trusting a recommendation?
Start with the evidence package: source system, timestamp, severity, asset or account identity, matched related evidence, and whether a person has reviewed it.
Glossary
Shared words for the workflow.
- Source
- A connected tool or imported evidence provider, such as RMM, PSA, MDR, billing, cloud, or observability data.
- Readiness
- The combined setup state for fields, credentials, validation, sync support, and evidence usefulness.
- Evidence package
- A review bundle for one imported event, including lineage, sync context, and related evidence candidates.
- Operator action
- A structured next step that tells the UI what a person should fix or review next.
- Governed action
- A write-back or remediation action controlled by policy and human approval.
