TvRMM is shaped around the operational traps customers already know from the RMM market: stale billing, weak exports, hostile cancellation, silent vendor access, and platform claims that make customers guess what actually works.
Each promise has a customer outcome, product mechanisms that make it real, and public evidence customers can inspect.
Stale, duplicate, retired, and forgotten agents should not stay on the bill forever.
Billing lines tie back to active-agent history, account credit, stale-agent exclusion, and refund records.
Customers should be able to protect the bill before a rollout grows unexpectedly.
Billing controls sit with tenant administration and are documented in the billing policy.
Customer data should be practical to retrieve before, during, and after cancellation.
Export, wind-down, retention, and deletion expectations are published in help and legal pages.
Endpoint, tenant, script, log, and billing data should not be sent to AI systems by default.
The privacy policy and terms publish the opt-in and bring-your-own-key AI stance.
Leaving the product should not require fighting the product.
Agent cleanup is part of the help center, not a support-only script hidden from customers.
Support should not silently enter a customer tenant.
The public security page and support policy make customer-approved support access explicit.
A platform logo should never make customers guess what actually works.
The platform page explains each platform in customer terms: what it is good for, when to involve support, and when an in-guest agent is needed.
Core customer protections should survive normal ownership changes.
Legal, billing, support, retention, and security-disclosure policies are published as part of the product surface.
Promises are only useful when they map to something visible in the product, help center, billing policy, or security model.
Daily snapshots, true-ups, account credit, stale-agent exclusion, refund review, and Stripe records make invoices traceable.
Tenant export, queued uninstall, manual cleanup guidance, and wind-down access are treated as normal workflows.
Future AI features are framed as explicit opt-in workflows using customer-controlled provider keys, not default processing by TvRMM.
Portal sessions, role-gated actions, operating-as role caps, and customer-approved support access reduce silent authority.
Agent platform support is stated by customer workflow, so customers can see where TvRMM is supported, install verified, guided-fit, or inventory-only.
Policy Center consolidates recurring controls for audit, logs, patching, scripts, monitoring, deployment, updates, and remote access.
mTLS agents, certificate revocation, CRLs, trust refresh, endpoint deletion, and remote-access gates are part of the product shape.
The company stance is customer-centric only if day-to-day product decisions follow the same pattern.
| Scenario | Expected product behavior |
|---|---|
| When billing is unclear | The answer should come from the ledger, not a sales exception. |
| When a device is stale | The system should stop billing it after the published offline window. |
| When a customer leaves | The product should preserve export, cleanup, and uninstall paths long enough to migrate safely. |
| When AI could be useful | The customer should choose whether to enable it and which provider key controls the data path. |
| When support is needed | Support should ask for customer approval and leave an audit trail. |
| When a feature is partial | The site should say what customers can use today and when they should involve support. |
| When a workflow repeats | It should become policy-driven instead of hiding as a one-off endpoint setting. |