Straight answers, including the inconvenient ones.

SiteOps Command is a facility-technology design platform. You build a single digital model of a building, floor by floor, with real walls, doors, and ceilings, and that one model drives the design work for every low-voltage and infrastructure system inside it: network, cabling, power, Wi-Fi, cameras, access control, AV and paging, plus the commercial paperwork and field-delivery reports the project needs. It is built for the design and delivery side of a facility technology project, not for running a help desk or general-ledger accounting. The goal is to remove the copy-paste and re-measurement that happens when every trade keeps its own drawing.

Nine disciplines sit on the shared building model: the building shell itself (walls, doors, ceilings), network topology and rack/patch planning, structured cabling and fiber backbone, electrical power and UPS/thermal sizing, Wi-Fi RF propagation, camera coverage and DORI compliance, access control and door hardware, AV and paging room design, and the commercial layer (BOM, quoting, invoicing). Each one runs real calculations against the model rather than just placing symbols on a canvas, and every discipline feeds a delivery layer of field tools and export documents that closes the project out.

Yes. A single project carries the building model through every discipline: wall and door modeling, network topology and rack elevations, cabling and fiber backbone, power and UPS sizing, Wi-Fi RF planning, camera coverage, access control, and AV/paging design. You are not switching tools per trade; the same floor plan and the same placed devices feed all of it, and the delivery layer produces field tools and as-built packages against that same project. It is not scoped to one room or one system category, though a single-room job, one conference room or one server closet, runs through the same engines at a smaller scale.

One model. Wall and material data is entered once, and both the Wi-Fi RF-attenuation engine and the camera and rack occlusion engine read from that same record rather than a technician keeping separate copies in sync. Network topology is a pure function of the devices actually placed in the model, so the same design always derives the same topology instead of being redrawn by hand for each trade. That shared-source design is deliberate: it is what keeps disciplines from drifting apart as a project gets edited over the life of a job.

Camera line-of-sight and Wi-Fi signal prediction both read from the same wall and material record, so a moved wall carries into both by construction rather than requiring you to re-enter it in two places. Network topology is likewise derived from the devices you have placed, not hand-drawn, so it reflects the current layout when you regenerate it. This does not mean every export re-renders itself the instant you drag a wall; it means there is one source of truth behind the recalculation, so re-running coverage or RF after the move gives you a result that matches the new geometry.

Not in the sales-pipeline sense. The platform carries a commercial layer built on top of the design data: quote building with a versioned approval workflow, quote-to-order-to-invoice conversion, invoicing and AR with a real risk model, and renewal tracking that can auto-spawn a new discovery session. What it is not is a general-ledger accounting system; there is no chart of accounts or double-entry ledger behind it, so it sits alongside QuickBooks, NetSuite, or Sage rather than replacing them. Think of it as the design-to-commercial handoff, not a full financial system of record.

Two honest gaps worth naming up front. It is not a general-ledger accounting system: invoicing and AR live inside it, but there is no chart of accounts or double-entry ledger, so it will not replace QuickBooks, NetSuite, or Sage. And it is not a service desk, ticketing system, or RMM platform: no plan includes a helpdesk console, and there is nothing resembling remote monitoring and management or a standalone PSA product. (Getting support FROM us is separate and included on every plan.) Both are deliberate scope decisions; the platform's job is designing and delivering the facility build, not running your ongoing MSP operations afterward.

A drawing tool records shapes. This platform runs the physics and math behind each shape: camera placement comes out of a deterministic line-of-sight and DORI-distance advisor rather than a guess, Wi-Fi coverage comes out of a shared RF-propagation engine using standards-based path loss and diffraction rather than painted circles, and network topology is derived from the devices actually placed rather than redrawn by hand. The as-built and installation-drawing exports, including true-scale CAD output, come out of that same calculated model instead of a separate illustration pass. The drawing is a view onto the calculation, not the other way around.

Both, on the same engines. The facility model handles a single floor or a multi-floor building with GPS-anchored floor plans, so a one-room AV retrofit and a multi-building rollout with its own MDF/IDF closets and rack elevations run through the same underlying calculations at different scale. There is no artificial floor on project size built into the platform's design engines; scope is set by how much of the building you model, not by a tier the software enforces.

Partly, by design. It replaces the drawing-and-spreadsheet layer: the BOM is auto-derived from placed devices with sealed revisions, labor and cost estimating produce a reproducible ROM budget, and quoting carries its own versioned approval workflow, so Visio-plus-spreadsheet estimating for a facility build is largely absorbed. It does not replace your PSA, RMM, or ticketing system, and it does not replace your accounting system; there is no general ledger behind it. The honest framing is design-and-delivery platform, not an all-in-one operations stack.

Topology is derived automatically from the placed design across five tiers: WAN, perimeter, core, distribution, and access. It is a calculation over your actual placed devices and connections, not a diagram a designer draws by hand, so the same design always regenerates the same topology. That means the topology view stays consistent as the design changes instead of drifting from an old snapshot someone forgot to update. It reads the network the way you actually built it, tier by tier.

Not as a dedicated diagram file today. The platform gives you an interactive topology view to work in on screen, and an as-built topology section is included in the delivery package, but there is no standalone exportable topology diagram, PDF or PNG, that you can hand off on its own. If your workflow needs a printable topology sheet separate from the rest of the as-built set, plan to produce that piece outside the platform for now.

Yes. MDF and IDF closets are modeled as their own facility elements, distinct from the racks placed inside them, so closet-level planning, location, capacity, and relationship to the floors and zones a closet serves, sits alongside the rack elevations rather than being inferred from rack placement alone. That closet layer is what lets the platform derive network topology and generate closet-specific schedules without treating every closet as an undifferentiated stack of racks.

Yes, in both 2D and 3D, generated at design time and ordered per BICSI TDMM conventions. Every equipment-placement suggestion carries its standard reference, rack-unit assignment is tracked per device, and the same model produces an as-built rack export once installation is complete. The elevation an installer works from during the build and the one in the closeout package come from one source, not two separately maintained drawings that can quietly drift apart.

Both directions are planned and tracked: switch-port assignment following BICSI and TIA-606 conventions, and patch-panel assignment that follows a device through to its panel and on to its switch, with both sides of the panel connection recorded. A technician can trace a cable from the wall jack to its panel port to its switch port without cross-referencing separate spreadsheets, and the same assignments feed the cable schedules and rack elevations.

No. VLAN groupings are generated as suggestions based on the design, but the platform never pushes configuration to network hardware. A designer or engineer reviews the suggested groupings and applies them through their own switch management workflow. Treat the output as a starting scheme worth validating against your actual switch environment, not a live configuration change made on your behalf.

Copper category validation covers Cat5e through Cat8 against ANSI/TIA-568 distance, bend-radius, and PoE-support limits for every category, though the survey's cable-path drawing tool only places Cat6, Cat6a, and Cat7 runs on the canvas today, so validation covers more categories than you can visually draw. Fiber is supported as a type registry, OM1 through OM5 and OS1/OS2, with backbone planning by strand count and TIA-598 color reference. That plans how many strands a backbone needs, not a strand-by-strand assignment of which strand carries which circuit.

Both a manual routing tool and an opt-in solver are available. The solver models capstan pull tension along the actual path and automatically splits a run where it exceeds bend-radius, tension, or length limits, rather than assuming an idealized straight pull. That keeps a route that looks fine on the drawing from turning out to be un-pullable through conduit and around real corners once a technician is on site with the reel.

Cable lengths are calculated including service loop and validated against copper and fiber distance limits under TIA-568, then roll up automatically into cable and drop schedules labeled per TIA-606-D administration conventions. That length calculation is scoped within a floor. Floor-to-floor height is captured in the model, but it is not yet consumed by the length calculation for runs that cross floors on a riser, so a cross-floor length still needs a manual check today.

Yes. PoE budget and headroom are calculated per IEEE 802.3bt, applying the standard 20 percent power and 25 percent port headroom margins so a switch's usable capacity is planned conservatively rather than to its nameplate maximum. That budget draws on the same device and port assignments used in the rack and cabling plan, so a switch choice that looks fine on paper but would run out of power headroom gets flagged during design instead of during install.

Yes to both, as planning-grade calculations. UPS sizing and runtime follow IEEE 485-2020 and are explicitly labeled a planning estimate, not a certified battery study. Thermal load is calculated in BTU per ASHRAE guidance and corrected for altitude, so a high-elevation site gets a load figure adjusted for thinner air rather than a sea-level number applied everywhere. Use both to size equipment with confidence; route anything requiring certification to a battery or mechanical engineer.

Circuit and breaker sizing follows NEC 240.6(A) and the NEC 210/215/220 load-calculation rules, applying the standard 125 percent continuous-load rule and stepping up to the next standard breaker rating, plus voltage-drop calculation at 3 and 5 percent thresholds. Electrical safety screening for arc-flash and short-circuit exposure is also included, referencing IEEE 1584-2018 and IEEE 141, but it is explicitly framed as a screening tool, not a certified arc-flash study. A certified study still requires a licensed electrical engineer.

Start with the capability matrix. It publishes every capability in one table with its status — shipped, partial, or not available — and the standard behind it, including the fifteen things the platform does not do. There is a machine-readable version at the same URL with a .json extension, rendered from the same source so the two cannot disagree. Beyond that, ask for a working session on your own floor plan: bring a building you have already designed the old way and compare what the model computes against what you concluded by hand. That is a harder test than any page, and it is the one we would rather be judged on.

Camera coverage is calculated against IEC 62676-4 DORI tiers: Detect, Observe, Recognize, Identify, each defined by a minimum pixel density on target. You set the target tier per zone, Identify at a building entrance, Detect across an open lot. For every camera and lens combination, the platform calculates the maximum distance at which that pixel-density threshold is met, so one camera can show a shorter Identify range and a longer Detect range in the same view. This keeps the coverage claim tied to a published standard rather than a generic field-of-view circle, and lets a design team defend camera counts and lens choices zone by zone instead of applying one blanket spec to the whole facility.

Yes. Field of view is projected using the real lens geometry, rectilinear, fisheye, and 180-degree or 360-degree panoramic, rather than a generic cone, and varifocal lenses are interpolated between their datasheet endpoints instead of averaged. On top of that, every camera gets a rendered 3D point-of-view and a POV report, so you can see the actual framed image a camera will capture from its mounted height and angle before it goes on a wall. That combination catches placement mistakes a flat coverage diagram misses, a fisheye mounted too low, a panoramic unit aimed into a support column, while giving the customer a concrete picture of what they are buying.

The IR range comes straight from the camera's datasheet, so the reach number is only as good as the manufacturer's published spec. Where the platform adds its own math is the 3D beam angle used to draw that reach in the scene, and that angle is indicative rather than a published datasheet value. In practice, treat the distance as the vendor's stated IR range and the cone shape as a reasonable visualization rather than a beam specification. That distinction is stated plainly rather than presented as more precise than it is.

Yes. Coverage is calculated with height-aware shadow casting against the same occlusion model used throughout the building, walls, equipment racking, and ceilings all block a camera's line of sight the way they would in the real room. One occlusion engine feeds both the interactive canvas and every export, so a coverage gap you see while placing a camera on screen is the same gap that appears in the exported coverage map and heatmap later. There is no separate, looser model doing the math for the printed deliverable than the one doing the math on screen.

No, and this is a deliberate distinction rather than an oversight. For cameras, a window is correctly treated as see-through, so a camera can look through glass to cover the space beyond it. A glass wall, however, blocks camera line of sight the same as a concrete wall would; the model does not yet differentiate glass from any other opaque material for occlusion. Wi-Fi works on a different axis: RF attenuation is driven by material and thickness, grounded in NIST IR 6055, so glass, drywall, and concrete each carry their own signal loss per band, and the same wall data does not drive camera occlusion. Do not expect glass and concrete to behave identically across both.

Yes, for both. Camera coverage heatmaps are generated per DORI tier, so you can visualize where a space is only detected versus where it is actually identified, with the exported image matching what the canvas shows. Wi-Fi heatmaps are generated per band, 2.4, 5, and 6 GHz render as separate layers rather than one blended signal picture, in both 2D and 3D, so a weak pocket on one band that is fine on another is visible instead of averaged away. Both heatmap types export directly into a proposal or as-built package.

Yes to both. The camera placement advisor is a deterministic, physics-confirmed engine, it proposes positions based on the same DORI, occlusion, and lens-geometry math described elsewhere, not a rough estimate. PTZ cameras are supported with simulation of their pan/tilt/zoom range, so a PTZ's coverage can be evaluated across its full sweep rather than only at one fixed preset. Placement suggestions and PTZ simulation both run on the same coverage engine that drives the heatmaps and POV reports, so a recommended position is backed by the same math the customer sees in the deliverables, not a separate estimate.

The RF engine runs one shared propagation calculation that feeds the heatmap, the AP planner, the walkthrough, and remediation alike, so every surface works from the same physics rather than separate approximations. It combines standards-based path loss with knife-edge, UTD, and Deygout multi-edge diffraction per ITU-R P.526, complex-permittivity reflection, and uplink/downlink asymmetry. Antenna behavior is included too, with one caveat: per-model radiation patterns are derived from a vendor's published gain and beamwidth figures rather than an imported measured pattern file, so treat them as a close approximation of the real antenna rather than a lab-measured plot.

Yes. If you have measured RSSI readings from a location, the platform corrects its predicted signal against them, tightening the model's accuracy for that specific building rather than relying purely on the generic propagation math. This is a calibration input, not a capture pipeline, you enter readings you already have; the platform does not include its own scanning hardware or a built-in way to gather them. A handful of spot readings in a couple of representative rooms tends to improve confidence in the predicted coverage for the rest of the floor.

Yes. The AP auto-planner places access points to meet coverage and capacity targets, with per-zone RF parameter overrides where a zone needs different assumptions than the rest of the building, and it can plan spare APs for redundancy where a zone calls for it. Channel planning runs alongside placement, you can apply or revert a channel plan, and it respects DFS eligibility and 6 GHz AFC rules rather than assigning channels blind. One caveat: the platform discloses spare AP counts as part of the plan, but has not proven a failover-safe acceptance threshold, so treat redundancy planning as a documented starting point, not a certified failover guarantee.

No. There is no working integration with spectrum-analyser hardware, and the platform does not scan RF spectrum for interference. What it does instead is predictive: the propagation engine models expected coverage and channel conflicts from the building's geometry, materials, and AP placement, and field calibration lets you fold in real RSSI readings if you have them. If a customer's problem specifically requires hunting an unknown interference source in occupied spectrum, that calls for dedicated spectrum-analysis hardware and a site visit, not this platform.

No. The platform does not ship or integrate with dedicated survey capture hardware, site Wi-Fi data is entered and predicted, not captured live from a scanning adapter or sensor. What it provides instead is the predictive RF propagation engine covering path loss, diffraction, material attenuation, and antenna behavior, plus a field-calibration step where you enter real RSSI readings gathered with whatever measurement tool you already use, to correct the prediction. If your process depends on a walk-around capture device as the primary data source, plan to bring your own; this platform is the design and prediction layer around it.