Hotam reads what a project promised, checks the real systems it touched, and shows exactly what passed, what failed and the evidence behind it. A project closes when the intended state exists and the evidence proves it, not when someone clicks Complete. Onboardings, migrations, server and firewall implementations, security rollouts, network refreshes: any project with a promised outcome. Built first for IT service providers. Designed for every industry where "done" and "correct" are not the same word.
Not a dashboard and not a ticket checker. Hotam takes responsibility for the acceptance layer of the business: what was promised, what actually exists, what evidence proves it, and what still blocks the project from being called complete.
One screen per project: what was promised, what we found, where it came from, what passed, what failed, what happens next.
Source, timestamp, expected, observed and the named devices or users that failed. Immutable once written.
Passed, Failed, Warning, Unknown. When evidence is missing the answer is Unknown, never a guess.
Define what a managed workstation or a managed user means in your shop. Stack standards per project. Mark what is critical.
Every project waiting for action in one list: ready, failed, needs review, ready for rerun, verified.
Every unresolved gap across every client, with severity, affected items and history. Nothing closes by clicking.
Rack cabling, training, physical work: a human signs for what software cannot see, and the signature is kept.
A client passes onboarding in January. Hotam keeps asking whether the environment still matches the standard it passed.
Onboarding is the example because everyone knows it. Hotam verifies every kind of implementation your PSA tracks: each project type is a template of controls, each control is checked against the systems that hold the evidence, and each result is explained.
Users, endpoints, RMM, EDR, licensing, MFA, backup, monitoring, documentation. All of it, proven, before the handoff.
Expected users migrated, licenses assigned, domains verified, MFA and security defaults enforced, mailboxes and groups in place.
Server exists and reports, roles configured, backup job succeeding, monitoring active, patching policy applied, documented.
New device online, old device retired, required policies present, VPN and logging configured, monitored by your network tool.
Switches, access points and circuits replaced as scoped, every device discovered and monitored, configs backed up, diagram updated.
EDR, DNS filtering, application control, encryption and MFA deployed to every in-scope endpoint and user, with the stragglers named.
Every device present in the new platform, none left behind in the old one, policies and alerts recreated, old agents removed.
New machines enrolled, encrypted, protected and monitored; retired machines removed from every console and from the client's licensing.
Network, endpoints, printers, phones and access controls delivered as scoped, physical work attested by the technician on site.
Account, license, groups, MFA, mailbox, device, RMM, EDR and the client's own policies. Small project, same standard.
Access revoked everywhere, licenses reclaimed, devices wiped or returned, data retained as agreed, nothing still reporting.
Any repeatable implementation becomes a template: pick the controls, set the expected values from the scope, run it every time.
Hotam is not an AI reading your tickets and giving an opinion. It is a pipeline: AI turns the promise into checkable requirements, read-only connectors collect the facts, and a deterministic engine compares the two. The result is auditable line by line, and it is never an opinion.
A project hits Ready for QA in your PSA. Hotam pulls the scope, the SOW, the tickets and the products sold, and AI turns the language into structured requirements with counts and values. You review and edit them before anything runs. AI only fills in blanks; it never grades.
| Requirement | Resource | Expected | Source sentence |
|---|---|---|---|
| RMM agent installed | Endpoint | 73 | "onboard 73 Windows endpoints into RMM" |
| EDR active | Endpoint | 73 | "…and endpoint protection" |
| Migrated to Microsoft 365 | User | 85 | "migrate approximately 85 users" |
| Business Premium license | User | 85 | "to Microsoft 365 Business Premium" |
| MFA enforced | User | 85 | "enforce MFA for all active users" |
| Backup configured | Server | 4 | "configure Cove backup for the 4 servers" |
| Rack cabling completed | Manual | , | Added by reviewer |
Read-only connectors pull the observed state from the systems where the work actually lives: which devices report to the RMM, which ones the EDR console can see, which users have MFA, which servers had a successful backup last night. Each fact carries its source and the time it was observed.
| Subject | Attribute | Source | Value | Observed |
|---|---|---|---|---|
| PC-JSMITH | rmm.installed | NinjaOne | true | 2 h ago |
| PC-JSMITH | edr.active | SentinelOne | no record | , |
| LAPTOP-023 | edr.active | SentinelOne | no record | , |
| WS-FINANCE01 | edr.active | SentinelOne | true | 3 h ago |
| jdoe@abcmfg.com | m365.mfa | Microsoft 365 | false | 14:01 |
| bthomas@abcmfg.com | m365.license | Microsoft 365 | Business Standard | 14:01 |
| SRV-FILE02 | backup.healthy | Cove | last job failed | 3 d ago |
| Tenant | dns.filtering | DNSFilter | configured | 14:02 |
The engine applies one rule per control: every in-scope device must have the attribute, every user must hold the license, the count must match. The output is one of four states, and the explanation is generated from the rule itself, so it reads the same way every time.
| Requirement | Expected | Found | Result | Evidence |
|---|---|---|---|---|
| RMM agent installed | 73 | 73 | Passed | NinjaOne |
| EDR active | 73 | 69 | Failed | 4 missing devices |
| Migrated to Microsoft 365 | 85 | 85 | Passed | Microsoft 365 |
| Business Premium license | 85 | 83 | Failed | 2 users |
| MFA enforced | 85 | 80 | Failed | 5 users |
| Backup configured | 4 | 3 | Failed | SRV-FILE02 |
| Documentation complete | 12 | 10 | Warning | 2 records |
| Rack cabling completed | , | , | Unknown | Attestation needed |
A failed requirement becomes a finding: severity from your standard, the affected devices or users by name, the source, the time, and a history of every run that checked it. Engineers get a list, not a hunch. Managers get an answer to "why did this fail?" without opening five consoles.
4 endpoints missing SentinelOne EDRPC-JSMITH, PC-MJONES, LAPTOP-023, WS-ACCOUNTING04 · in NinjaOne scope, not present in SentinelOne5 users without MFAjdoe, asmith, bthomas, mjohnson, rwilson · Microsoft 365, 14:01 UTC1 server backup not reportingSRV-FILE02 · Cove, last successful job 3 days ago2 users with wrong licensebthomas, kpatel · Business Standard, expected Business Premium2 documentation records missingNetwork Diagram, Backup Runbook · IT GlueEngineers fix the gap in the real systems. You rerun. Hotam collects fresh evidence, compares again, and resolves each finding only if its requirement now passes. Manual items are attested by a named person with a timestamp. When everything passes, the project is Verified, and that word means something.
Fresh evidence collected 09:40 UTC. The four devices now report to SentinelOne, five users have MFA, SRV-FILE02 completed a backup, licenses corrected, records added. Rack cabling attested by Mike Torres.
Every MSP defines a managed workstation differently. One requires NinjaOne, SentinelOne and DNSFilter; another runs Datto, Huntress and ThreatLocker. Hotam does not hard-code a universal answer. You build standards from a library of vendor-neutral controls, stack them on a project, and mark which ones are critical enough to fail it.
A client passes onboarding on January 5. By April, two agents are gone, three users turned off MFA, and a server's backup has been failing quietly for a week. Hotam keeps the baseline from the day the project was verified and keeps asking whether the environment still meets it.
| Control | Baseline | Today | Change | |
|---|---|---|---|---|
| RMM agent | 73 / 73 | 73 / 73 | , | Holding |
| EDR active | 73 / 73 | 71 / 73 | −2 | Drifted |
| MFA enforced | 85 / 85 | 82 / 85 | −3 | Drifted |
| Licensing | 85 / 85 | 85 / 85 | , | Holding |
| Backup healthy | 4 / 4 | 3 / 4 | −1 | Watch |
| DNS agent, 48 h | 73 / 73 | 73 / 73 | , | Holding |
We are not building a QA tool for onboardings. We are building the layer that proves operational work was done correctly, and IT service providers are where we prove it first, because the evidence already lives behind APIs and the founders know the work. Each phase is unlocked by the one before it.
Strip the IT vocabulary away and the question is the same everywhere. A work order, a shipping requirement or a definition of done says what should happen. An MES, a scanner or a CI pipeline records what did. Hotam compares them, with evidence, and decides. Domain partners from each industry shape its pack; MSP expertise does not transfer to a factory floor on its own, and we are not pretending it does.
| Industry | Expected state from | Observed state from |
|---|---|---|
| IT and MSP | Scope, SOW, PSA project, products sold, standards | PSA, RMM, Microsoft 365, EDR, backup, network, documentation |
| Manufacturing | Work order, SOP, BOM, quality plan, tolerances | MES, QMS, ERP, PLC and IIoT telemetry, inspection systems |
| Warehousing | Receiving SOP, pick and pack rules, chain of custody, cutoffs | WMS, barcode and RFID scans, inventory, dock and shipment records |
| Software delivery | Ticket, definition of done, release checklist | CI/CD results, test coverage, code scanning, deployment records |
| Field service | Scope, installation checklist, maintenance standard, safety rules | CMMS, technician records, device telemetry, photographs, sign-off |
| Regulated operations | Required controls, policies, approvals, procedures | Logs, configurations, approval records, control evidence |
Every implementation type, verified against PSA, RMM, Microsoft 365, EDR, backup and documentation.
Phase 1 · available nowWork orders and quality plans versus MES, QMS, ERP and machine telemetry.
Phase 4 · first pilotsPicking, packing and chain-of-custody rules versus WMS scans, RFID and dock records.
Phase 4 · first pilotsDefinition of done and release checklists versus CI results, scans and deployment records.
Phase 4Installation checklists and maintenance standards versus technician records, telemetry and sign-off.
Phase 4Inspection schedules and safety requirements versus CMMS, sensors and photographs.
Phase 4Scope and punch lists versus inspection records, photos and change orders.
LaterRequired controls and procedures versus logs, configurations and approval records. Continuous, not annual.
LaterRead-only, always. Hotam asks to verify your environment, never to change it. Least privilege, tenant isolation, encrypted credentials, full audit log. Your design-partner stack gets built first.
Short reads on what changes when a company can prove its work was done correctly, and why "completed" has been letting everyone down.
One onboarding that closes with four unprotected machines costs more than a year of Hotam. We are taking three MSPs into a founding design-partner program before general availability.
Prices are working hypotheses for the pilot program and will be set with design partners.
Most manual QA takes hours per project and still relies on someone comparing lists across five consoles by hand. Hotam does that comparison in minutes, every time, and leaves the evidence behind. Your senior people review the exceptions instead of verifying everything.
No. Every integration is read-only. Hotam asks to verify your environment, never to modify it. Remediation actions, when they arrive, will sit behind explicit approval and remain optional.
Ticket QA checks whether the ticket was well documented. Hotam checks whether the outcome exists: it asks the EDR console how many endpoints are protected, not the ticket. A perfectly written ticket that says "deployed to 73" still fails when the console shows 69.
Monitoring tools tell you what exists and what changed. Hotam starts from what was promised for a specific project and proves whether every required outcome was delivered before you accept it. Continuous assurance then watches for drift from that verified baseline.
The result is Unknown, never Passed. A connector outage produces Evidence Unavailable. Two sources that disagree produce a Warning that shows both values. Hotam does not guess, and it does not hide uncertainty to make a screen look green.
No. The product never reads who attested, acted or fixed anything into any report, and a test fails if a person's name leaks into the dashboard. The goal is operational quality, not surveillance.
An isolated tenant in an encrypted database. One MSP can never see another's data, enforced at the database layer. It is never used to train anything. Disconnect any time.
A read-only connection takes minutes. The first project runs through QA the same day. The first finding you did not know about usually arrives in the first week.
Bring one real project. Hotam reads the scope, checks the systems, and shows you what your last QA missed. If it finds nothing, you have proof. If it finds something, you found it before your client did.