Industry solution

IT, Cloud & Managed Services

Know what you run, what it costs, and who fixes it when it breaks

Inventory, CMDB, licenses, cloud spend, patching and on-call, joined up for infrastructure teams and managed service providers.

Products
8
Challenges
6
Concepts
15
Talk to us about IT & CloudAsk a question
Engineers at a managed service provider reviewing an infrastructure dependency map, patch progress and cloud costs on large monitors
AdapterCloud(opens AdapterCloud in a new tab)AssetHandler(opens AssetHandler in a new tab)Subscriber Bot(opens Subscriber Bot in a new tab)VibeControls(opens VibeControls in a new tab)FluidGrids(opens FluidGrids in a new tab)Botlit(opens Botlit in a new tab)BigConsole(opens BigConsole in a new tab)TimeCampus(opens TimeCampus in a new tab)

The problem

Why running an estate got harder, not easier

Everything the team runs is spread across several cloud providers, rented data-center space, dozens of admin screens for online software and a register of systems nobody trusts. Every question about cost, ownership or what a failure would take down starts days of spreadsheet archaeology.

Many infrastructure teams now run across more than one public cloud, several Kubernetes clusters, a colocation or on-prem footprint and a long tail of SaaS tenants. Each has its own console, its own identity model and its own bill. The inventory is a spreadsheet exported last quarter, and the CMDB was accurate the week it was loaded. When a change goes wrong, the first half hour of the incident is spent working out what depends on what.

Spend and licensing have drifted out of IT's hands. Engineers create resources in minutes, teams buy SaaS on corporate cards, and renewals roll over on notice periods nobody tracked. FinOps practitioners chase untagged spend line by line, and software asset managers rebuild an effective license position by hand every time a vendor sends an audit letter.

Managed service providers carry all of this multiplied by every client, usually on fixed-fee contracts with thin margins. Their engineers switch between client estates all day, patch windows stack up after every critical advisory, and the quarterly business review is assembled from five exports the night before. The individual tools are rarely the problem; the gaps between them are.

Who this is for

  • Head of infrastructure or platform

    One live inventory and dependency map across clouds, clusters and on-prem, so change risk and ownership are answers rather than guesses.

  • MSP service delivery director

    Forty client estates run with one operating model, clean separation between clients, and SLAs and hours visible per client.

  • FinOps lead or cloud cost owner

    Spend attributed to resources and owners, untagged cost shrinking, and a month-end showback that budget holders accept.

  • IT and software asset manager

    A CMDB that matches reality, a license position ready before the true-up, and seats reclaimed soon after a leaver exits.

  • SRE or on-call engineer

    Runbooks that find you at 3 a.m., a safe way to pull in a senior engineer, and patch windows that do not end in pages.

  • IT security and compliance lead

    Shadow IT found before it holds sensitive data, drift and waivers with a reason on record, and one audit trail across tools.

A day in the life

The story behind the solution

A week at an MSP that runs forty client estates

Nadia's team looks after about forty client estates: three public clouds between them, two colocation cages, hundreds of Windows and Linux servers and more SaaS tenants than anyone has counted. Her engineers are good. What wears them down is the space between systems: discovery that disagrees with the CMDB, the license spreadsheet, the cloud bill nobody can explain, and the runbook that lives in a former colleague's head. This is one ordinary week.

  1. Monday, 07:40

    The handover spreadsheet that was already wrong

    Kestrel Bay takes over running Larkspur Freight's systems today. The previous provider's handover sheet lists 212 servers and two cloud accounts. By mid-morning the team has found a third account paying for a forgotten analytics system, and a database server the system register marks Operational that was switched off in the spring. Nobody can say which applications depend on the storage hardware due for replacement next month.

    How this is solved: A CMDB and inventory that match what is actually running

  2. Monday, 14:10

    An audit letter and fourteen unknown card charges

    Fernhall Legal forwards a letter from its productivity-suite vendor asking for a license count within thirty days. The same afternoon its finance lead sends an expense export with fourteen recurring software subscription charges IT has never seen. One of them is a file-sharing tool holding client documents, and three people who left in July still hold paid seats in it.

    How this is solved: Licenses, renewals and shadow IT with one owner each

  3. Tuesday, 09:05

    The cloud bill nobody can explain

    Calloway Dental Group's finance director emails a screenshot: the August cloud invoice is well above July's. A large share of the spend carries no cost-center label, shared network costs are split by a formula nobody remembers, and the question on the call is simple and awkward: which team caused this, and was it the provider's change?

    How this is solved: Cloud spend attributed to the teams and clients who drive it

  4. Wednesday, 21:30

    Patch night across 300 servers

    A critical security warning for widely used Linux software landed on Tuesday, and every client wants the fix in before the weekend. The team has a maintenance window from 22:00 to 02:00 for about 300 Linux servers across nine clients, each of which approves its own change. The plan is a spreadsheet, approvals sit in nine email threads, and the second batch of servers stalls when one rejects the update because someone changed its settings by hand last month.

    How this is solved: Patch windows that follow an approved plan, wave by wave

  5. Thursday, 03:12

    The page nobody wants

    Larkspur's order system starts failing to respond. The on-call engineer, Tomasz, is in his second week and has never worked on this client's systems. The step-by-step fix guide exists somewhere in a shared drive. He needs to know what sits behind the order system, whether last night's update touched it, and how to get a senior engineer into the same live server session without passing login details around in chat.

    How this is solved: On-call that starts with the runbook and the dependency map

  6. Friday, 16:00

    A quarterly review by Monday morning

    Quillon Parts, a client for six years, has its quarterly business review on Monday. Nadia needs hours used against the agreed block of support hours, performance against agreed service levels, incidents and changes, cloud spend against budget, and the warranties and support contracts expiring next quarter. In past quarters an account manager spent a day stitching five exports into slides, and the client still asked where the numbers came from.

    How this is solved: Client service reviews built from the record, not the night before

None of this is exotic. It is the normal texture of running infrastructure for other people. The idea behind the solution is that each of these moments starts from the same governed picture of the estate, and each product hands the next one something concrete instead of another spreadsheet.

Challenges and how they are solved

6 problems, several products, one connected answer

Each challenge shows the problem as it happens, how the products are designed to hand work to each other, and the concepts that illustrate it. Share any challenge on its own.

Answers are in plain business terms. Choose Technical, or open any technical detail, to see how it works under the hood.

Challenge 1 of 6

A CMDB and inventory that match what is actually running

AdapterCloud(opens AdapterCloud in a new tab)AssetHandler(opens AssetHandler in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

A managed service provider takes on a new client, or an infrastructure team inherits the systems of a company it acquired. The handover documentation is a spreadsheet from the previous provider, and a first scan soon turns up cloud accounts nobody listed and servers the system register still shows as live long after they were switched off. Entries have no owners, what depends on what was never recorded, and nobody can say what relies on the storage or network equipment due for replacement. Every change, incident and audit that follows inherits the uncertainty.

What it costs

Changes are approved against a system register that is wrong, incidents start with guesswork about what depends on what, and forgotten cloud services keep running up bills for months.

How the products work together

AdapterCloud is designed to keep a live list of everything running in your cloud accounts, and AssetHandler finds on-site equipment and holds the official register of systems. Every mismatch lands in one review queue, where someone adds, retires or merges an entry, or assigns an owner, after seeing what still depends on it. FluidGrids can send ownerless items to the right team and repeat the check on a schedule.

How it works — technical detail

Technical detail

AdapterCloud is designed to connect to each cloud account, cluster and on-prem target and keep a unified resource inventory and dependency topology current through discovery and reconcile runs. AssetHandler's own network discovery jobs cover on-prem subnets, so both sources feed the same queue. AssetHandler stays the system of record for configuration items, owners, hardware lifecycle and change history. The two are designed to meet in a reconciliation queue: each discovered resource is matched against a configuration item, and each mismatch becomes a decision to create, retire or merge a CI, or to assign an owner, with AdapterCloud's topology showing what still depends on it. FluidGrids can route unowned items to the owning team as tasks and re-run the check on a schedule.

The outcome it is designed for

Designed to give every change, incident and audit a system register that reflects what is actually running, with each correction attributed to a named person.

The concepts behind it

Challenge 2 of 6

Licenses, renewals and shadow IT with one owner each

Subscriber Bot(opens Subscriber Bot in a new tab)AssetHandler(opens AssetHandler in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

Vendor audit letters arrive with short deadlines, finance keeps finding recurring software subscription charges IT never approved, and leavers keep paid seats, and sometimes access to sensitive files, until someone notices at renewal. The true count of licenses owned and in use is rebuilt by hand for every audit, nobody owns the tools teams bought on corporate cards, and notice periods pass unseen, so unwanted renewals lock in for another year.

What it costs

Buying too many or too few licenses both cost money, unapproved tools hold sensitive data outside IT's controls, and leavers keep access and seats long after they exit.

How the products work together

Subscriber Bot is designed to keep every software subscription, renewal date and notice period in one place, and to flag unrecognized recurring charges for review. AssetHandler compares seats bought with seats used, so the license count is ready before a vendor asks. When someone leaves, FluidGrids can remove their access and hand the freed seats back to Subscriber Bot to downgrade or cancel before the notice period ends.

How it works — technical detail

Technical detail

Subscriber Bot is designed to be the system of record for recurring relationships: it brings SaaS subscriptions, renewal dates, notice periods, payment instruments and invoices into one portfolio, and is designed to surface unrecognized recurring spend as shadow-IT candidates for review. AssetHandler holds the installed-software and entitlement side, comparing seats purchased with seats used to produce a license position for the true-up. When a reviewer sanctions a tool in Subscriber Bot, it is designed to be registered in AssetHandler's software register with an owner and an entitlement count. When someone leaves, FluidGrids can run the offboarding workflow that removes access and hands the freed seats back to Subscriber Bot for a downgrade or cancellation before the notice period closes.

The outcome it is designed for

Designed to give IT one owner for every paid tool, a license count ready before the vendor asks, and seats reclaimed within days of a leaver's exit.

The concepts behind it

Challenge 3 of 6

Cloud spend attributed to the teams and clients who drive it

AdapterCloud(opens AdapterCloud in a new tab)FluidGrids(opens FluidGrids in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

The month closes and a budget holder, or a managed-service client's finance director, asks why the cloud invoice jumped. A large share of spend carries no cost-center label, shared costs for networking and common services are split by a formula nobody remembers, and last quarter's list of oversized cloud services to cut down was never acted on because no one owned the items on it. The cost analyst exports the bill into a spreadsheet to answer the only question that matters: which team drove this, and was it a change someone made on purpose?

What it costs

Budget holders dispute cost splits they cannot trace, unlabeled spend keeps growing, and savings conversations stall because nobody owns the systems in question.

How the products work together

AdapterCloud is designed to tie each cloud cost to the system and owner behind it and flag anything missing a cost-center label. It splits the month's spend by team or client, divides shared costs by a stated rule and keeps unlabeled spend as its own line. FluidGrids delivers that split to BigConsole on a schedule, where each budget holder sees only their share and can ask what changed.

How it works — technical detail

Technical detail

AdapterCloud ingests cost records against the same resources it discovers, so spend sits on the topology rather than on a service line, and a tagging policy is designed to flag resources missing a cost-center tag as violations with owners. Its showback view is designed to allocate spend to cost centers or clients by tag, split shared costs by a stated rule and keep unallocated spend visible as its own line. A FluidGrids workflow then pushes the published allocation into BigConsole data sinks on a schedule, where each budget holder is designed to see only their own slice and ask what changed, with the answer citing the resource and period behind it.

The outcome it is designed for

Designed so every budget holder sees spend they can trace to a specific system, and unlabeled spend becomes a shrinking to-do list rather than a monthly argument.

The concepts behind it

Challenge 4 of 6

Patch windows that follow an approved plan, wave by wave

VibeControls(opens VibeControls in a new tab)AssetHandler(opens AssetHandler in a new tab)AdapterCloud(opens AdapterCloud in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

A critical security warning lands and every client or business unit wants the fix in place within days. The maintenance window is a few hours overnight, the scope is hundreds of servers, the plan lives in a spreadsheet and approvals sit in separate email threads. Servers that someone changed by hand months ago reject the update partway through, and by the early hours nobody is sure which servers are done, which restarted and which need rolling back, so the change record says one thing and the servers another.

What it costs

Maintenance windows overrun, change records stop matching what was actually done, and servers changed by hand over time turn routine updates into an outage risk.

How the products work together

AssetHandler holds each client's approved change plan, and AdapterCloud flags servers that no longer match their intended setup, to fix or leave out before the maintenance window. VibeControls is designed to roll those changes out in waves, a small test group first, pausing if too many fail and recording every step. Results go onto each client's change record, and FluidGrids can raise follow-up tasks for servers skipped or rolled back.

How it works — technical detail

Technical detail

AssetHandler holds one change request per client: scope as configuration items, risk, window and each reviewer's approval. Before the window opens, AdapterCloud's drift records show which servers have diverged from their desired configuration, so they are fixed or excluded first. VibeControls is designed to run the approved changes as ordered waves on servers where its agent is installed, pilot first and then broad, using pre-approved Vibe Deck actions and Vibe Calendar scheduled tasks, pausing the next wave when failures pass a threshold and logging every command. Wave results are designed to be written back to each AssetHandler change request, and FluidGrids can raise follow-up tasks for servers that were skipped or rolled back.

The outcome it is designed for

Designed so a patch night ends with change records that match reality: which servers were patched, skipped or rolled back, by whom and when.

The concepts behind it

VibeControls

Patch Window Rollout Waves

Runs the approved changes as pilot and broad waves across agents, with per-server status, a failure threshold that pauses the next wave and a link to each client's change record.

Works with AssetHandler, AdapterCloud

Concept pagefor Patch Window Rollout Waves on the VibeControls website (opens in a new tab)

Challenge 5 of 6

On-call that starts with the runbook and the dependency map

Botlit(opens Botlit in a new tab)AdapterCloud(opens AdapterCloud in a new tab)VibeControls(opens VibeControls in a new tab)AssetHandler(opens AssetHandler in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

In the middle of the night a customer-facing service starts failing, and the engineer on call is new to that client's systems. The step-by-step fix guide is somewhere in a shared drive, the monitoring tools show the symptom but not what the service depends on, and nobody can say quickly whether last night's change touched the database behind it. Pulling in a senior engineer means sharing a screen over a call or passing login details around in chat, and the fix rarely makes it back into the guide for the next person.

What it costs

Engaging the right person takes too long, newer engineers escalate by default, and sharing login details mid-incident leaves no clean record of who did what.

How the products work together

Botlit is designed to answer the on-call engineer in the team chat from the step-by-step fix guides, showing the passages it used and saying plainly when nothing matches. AdapterCloud shows which systems the failing service relies on and what changed recently. VibeControls lets a senior colleague join the engineer's live server session through an expiring link, so nobody shares passwords, and FluidGrids opens the incident record in AssetHandler.

How it works — technical detail

Technical detail

Botlit is designed to run an on-call assistant in the team's chat channel, grounded in the runbooks and known-error articles AssetHandler keeps in Botlit knowledge bases, answering with the passages it used and saying plainly when nothing matches. AdapterCloud's topology shows what sits behind the failing service and which of those resources changed or drifted recently. When the engineer needs help, VibeControls shares the live terminal session with a senior colleague through an expiring link with a clear viewer or interactive role, so nobody hands over passwords. Botlit can trigger a FluidGrids workflow that opens the incident record in AssetHandler, and the eventual fix goes back into the runbook.

The outcome it is designed for

Designed to put a newer engineer in front of the right fix guide, a map of what the service depends on and the right colleague within minutes, with every step on the record of who did what.

The concepts behind it

Challenge 6 of 6

Client service reviews built from the record, not the night before

BigConsole(opens BigConsole in a new tab)TimeCampus(opens TimeCampus in a new tab)AssetHandler(opens AssetHandler in a new tab)AdapterCloud(opens AdapterCloud in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

Every quarter each client expects a business review: hours used against the support agreement, performance against agreed service levels, incidents and changes, cloud spend against budget, and the hardware and contracts reaching end of life. Each figure lives in a different tool, so account managers lose a day per client stitching exports into slides, and clients still ask where the numbers came from and how their data is kept apart from other clients'.

What it costs

Review prep eats senior time, figures are challenged because they cannot be traced, and scope creep on fixed-fee contracts goes unnoticed until renewal.

How the products work together

TimeCampus records engineers' hours, with their consent, against each client's budget of support hours; AssetHandler adds incidents, changes, results against agreed service levels and expiring warranties; AdapterCloud adds cloud spend. FluidGrids is designed to gather it all into BigConsole, which builds one review page per client showing only that client's figures. The account manager shares a read-only link or exports the review pack, and every number names its source.

How it works — technical detail

Technical detail

TimeCampus captures engineers' time against client projects with an hour budget, for example a 400-hour support block set up as a project budget, with consent and without surveillance. AdapterCloud provides the client's cloud spend and open policy violations, and AssetHandler provides incidents and changes with their SLA results, plus the warranties and support contracts expiring next quarter. FluidGrids workflows are designed to pull each of these into BigConsole data sinks, where one review console template is stamped out per client and is designed so each console reads only that client's rows. The account manager shares a read-only link or exports the pack, and every figure names the product it came from.

The outcome it is designed for

Designed to turn review prep from a day of exports into a check of one review page per client, with figures the client can trace to their source.

The concepts behind it

How it fits together

How it fits together: from discovered resource to client review

What the scans find updates the official register, the register decides which changes can go ahead, changes and incident work feed the numbers, and the numbers go back to the people who own them. Each step is one product doing one job and handing the next a concrete item.

  1. To AssetHandler: Anything running that the official register does not list yet

  2. To AssetHandler: Approved tools, each with an owner and a seat count

  3. To VibeControls: An approved change, ready to roll out in waves

  4. To AssetHandler: Server-by-server results: updated, skipped or rolled back

  5. To FluidGrids: A request to open an incident and alert the owning team

  6. To FluidGrids: Monthly hours used per client project

  7. To BigConsole: Cost splits, service performance and client hours, ready to show

Step 1 of 8: Discover and cost the estate

How each hand-off works — technical detail

Technical detail

  1. 1. AdapterCloud — Discover and cost the estate: Runs discovery, reconcile and cost-ingest syncs across connected cloud accounts and clusters, keeping inventory, topology, drift and cost current.Hands to AssetHandler: Resources with no matching configuration item are designed to go to the CMDB reconciliation queue.
  2. 2. Subscriber Bot — Catch recurring spend: Tracks every SaaS subscription, renewal and notice period, and is designed to queue unrecognized recurring charges as shadow-IT candidates.Hands to AssetHandler: Sanctioned tools are designed to be registered as software assets with an owner and an entitlement count.
  3. 3. AssetHandler — Keep the record: Reconciles the CMDB with its own network discovery, holds the license position, and records incidents and per-client change requests with approvals.Hands to VibeControls: An approved change request is designed to become a wave plan.
  4. 4. VibeControls — Run the change: Is designed to run approved changes as pilot and broad waves through its agents, pausing on failure thresholds and logging every command.Hands to AssetHandler: Wave results are designed to be written back to the change record; skipped servers and rollbacks go to FluidGrids for follow-up tasks.
  5. 5. Botlit — Answer on-call: Is designed to answer engineers in the team channel from runbooks and known errors with cited passages, and triggers workflows when action is needed.Hands to FluidGrids: A request to open an incident record in AssetHandler and notify the owning team.
  6. 6. TimeCampus — Capture client time: Records engineers' time against client projects with consent, and shows hours used against each project's budget.Hands to FluidGrids: Monthly hours per client project, designed to feed the reporting workflow.
  7. 7. FluidGrids — Route and feed: Routes tasks, offboarding steps and incident records between products, and pushes costs, tickets and hours into data sinks on a schedule.Hands to BigConsole: Governed data sinks for cost allocation, service performance and client hours.
  8. 8. BigConsole — Show each owner their slice: Is designed to publish showback consoles to budget holders and review consoles to each client, with rows separated by client and a source on every figure.

Products in this solution

What each product brings

  • AdapterCloud

    Inventory of everything running, dependency map, unplanned changes and cloud cost

    AdapterCloud is designed to bring cloud accounts, on-site servers and online services into one list with a map of what depends on what, plus the cost and any unplanned changes on each item. The other products work from this live picture.

    Technical detail

    Technical detail

    Is designed to connect cloud accounts, clusters, on-prem and SaaS targets into one inventory and dependency graph, with policies, drift records and cost records attached to the same resources. It is the live picture the other products work from.

    Visit AdapterCloudAll concepts

  • AssetHandler

    System register, change records and software licenses

    AssetHandler is the official register of your systems and equipment, with hardware life cycle, incidents, changes and software licenses, and it finds on-site equipment itself. It holds the ownership and history that a cloud scan alone cannot supply.

    Technical detail

    Technical detail

    The system of record for configuration items, hardware lifecycle, incidents, problems, changes and software entitlements, with network discovery jobs for on-prem subnets. It holds the ownership and history that cloud discovery alone cannot supply.

    Visit AssetHandlerAll concepts

  • Subscriber Bot

    Software subscriptions, renewals and unapproved tools

    Subscriber Bot keeps every subscription, license and contract on file with its plan, renewal date, notice period and invoices. It is designed to spot recurring spending that IT did not know about.

    Technical detail

    Technical detail

    Treats every subscription, license and contract as a relationship with a plan, renewal date, notice period and invoices, and is designed to surface recurring spend that IT did not know about.

    Visit Subscriber BotAll concepts

  • VibeControls

    Server operations, fix guides and shared work sessions

    VibeControls runs pre-approved actions and scheduled jobs on servers where it is installed, puts AI-suggested work in front of a person for approval first, and lets engineers share a live server session through a link that expires, with one record of who did what.

    Technical detail

    Technical detail

    Agents installed on servers run pre-approved Vibe Deck actions and Vibe Calendar jobs, Plan mode puts AI-proposed work behind a human review, and terminal sessions can be shared through expiring links, all under one audit log.

    Visit VibeControlsAll concepts

  • FluidGrids

    Workflows and hand-offs between products

    FluidGrids uses visual workflows to pass register mismatches, steps for staff who leave and follow-up tasks to the right product and team, and delivers cost splits, support tickets and hours to BigConsole on a schedule.

    Technical detail

    Technical detail

    Visual workflows route mismatches, offboarding steps and follow-up tasks between products, and data sink nodes push allocations, tickets and hours into BigConsole on a schedule.

    Visit FluidGridsAll concepts

  • Botlit

    On-call and service desk assistant

    Botlit puts an assistant in the team's chat that is designed to answer from the fix guides and known problems, showing the passages it used. It can also start follow-up work, such as opening an incident record.

    Technical detail

    Technical detail

    Governed agents in the team's chat channels are designed to answer from runbooks and known errors with cited passages, and can trigger workflows such as opening an incident record.

    Visit BotlitAll concepts

  • BigConsole

    Cost breakdowns and client review pages

    BigConsole builds one live board per budget holder or per client from a shared template, with sharing controls designed so each viewer sees only their own figures.

    Technical detail

    Technical detail

    Console templates are stamped out per budget holder or per client, fed by governed data sinks, with sharing controls and row separation designed so each viewer sees only their own slice.

    Visit BigConsoleAll concepts

  • TimeCampus

    Time against client projects

    TimeCampus records engineers' time against client projects with an hour budget, with consent and without surveillance. Team workload is shown only as totals, and each client gets a link to see their own hours.

    Technical detail

    Technical detail

    Captures engineers' time against client projects with an hour budget, with consent and without surveillance, keeps team load visible only in aggregate, and gives each client a share link to their hours.

    Visit TimeCampusAll concepts

One platform underneath: Burdenoff Workspaces

All eight products run on Burdenoff Workspaces: one sign-on, role-based access, one audit trail and one bill. Each client estate lives in its own workspace, so access and audit stay separate, while the MSP's operations workspace is designed to give engineers a cross-client view of assigned work.

Concept gallery

Every concept in this solution

15 concepts from 8 products. Each one links to its own page on the product's website, and every view has a link you can share.

Pitch kit

The IT & Cloud solution in one minute

Infrastructure teams and managed service providers lose their week in the gaps between tools: live scans that disagree with the system register, licenses in spreadsheets, cloud bills nobody can explain, update plans in email and fix guides nobody can find at 3 a.m. Burdenoff brings eight products together on one shared, access-controlled picture of all the systems in their care, so each of those moments starts from the same record and hands the next team something concrete.

  • AdapterCloud's live scans checked against the AssetHandler system register, so changes are approved against what is actually running
  • Subscriber Bot and AssetHandler together for renewals, unapproved software and a license count ready before the vendor asks
  • Cloud spend designed to be split by cost-center label in AdapterCloud and published to each budget holder through FluidGrids and BigConsole
  • Server updates rolled out in waves by VibeControls, tied to each client's change approvals in AssetHandler, with Botlit answering on-call engineers from the fix guides
  • Per-client review pages with TimeCampus hours, AssetHandler service-level results, cloud spend and expiring hardware and contracts, each figure traceable
Email it

Questions

Frequently asked

Does this replace our monitoring, RMM or ticketing tools?

Not necessarily. It is designed to sit alongside the tools you already run, and FluidGrids can pass information between Burdenoff products and your other systems. Many teams would start with one gap, such as keeping the system register accurate or tracking software renewals, and add more from there.

Technical detail

Technical detail

Not necessarily. The solution is designed to sit alongside the tools you already run. AdapterCloud models other systems through adapters, and FluidGrids workflows can move data between Burdenoff products and external systems through connectors, webhooks and an API. Many teams would start with one gap, such as CMDB reconciliation or SaaS renewals, and extend from there.

How are client estates kept apart for an MSP?

Each client's systems live in their own workspace, so access and the record of who did what stay separate. The provider's own operations workspace is designed to show engineers the cross-client work assigned to them, such as a patch night, and each client's review page shows only that client's figures.

Technical detail

Technical detail

Each client estate lives in its own workspace, so access and audit stay separate. Every Burdenoff product is workspace-scoped, with role-based access on every operation and one audit trail. The MSP's own operations workspace is designed to give engineers a cross-client view of work they are assigned to, such as a patch night, and the BigConsole review template is designed to be stamped out per client so each console reads only that client's rows.

Is all of this available today?

No. The products are pre-launch or early, and this page describes a solution concept: the register review queue, cost breakdown, update waves and client review page are proposed designs. The two documented links, FluidGrids sending figures to BigConsole and Botlit reading boards and starting workflows, are still being completed; the other hand-offs show the intended design.

Technical detail

Technical detail

The products are pre-launch or early, and this page describes a solution concept. Several surfaces shown here, including the CMDB reconciliation queue, cloud showback, patch waves and the client review console, are proposed designs. The integrations the products document are FluidGrids data sinks feeding BigConsole and Botlit agents querying dashboards and triggering workflows, and those are still being completed; the other hand-offs describe how the products are designed to work together.

Will the AI act on our infrastructure on its own?

Not for anything consequential; the design keeps people in charge. Botlit shows its sources, VibeControls can require a person to approve an AI-suggested plan before it runs, and Subscriber Bot proposes renewals and cancellations for a person to approve. Every action is tied to a named user and kept on the record of who did what.

Technical detail

Technical detail

The design keeps people in charge of consequential actions. Botlit is designed to answer with cited sources and say when nothing matches; VibeControls can require a human-approved plan before AI-proposed commands run; Subscriber Bot agents are designed to propose renewals and cancellations for a person to approve. Every action runs under a named identity and lands in the audit trail.

Does TimeCampus monitor our engineers?

No. TimeCampus is built to record work with consent rather than surveillance, and team views show totals only. For a managed service provider, the useful output is hours against client projects and a team-level view of workload, not a minute-by-minute record of each person.

Technical detail

Technical detail

No. TimeCampus is built to be privacy-first: it captures work context with consent rather than surveillance, and team views are aggregate. For an MSP the useful output is hours against client projects and a team-level view of load, not a record of what each person does minute by minute.

Where would a team usually start?

Wherever the pain is sharpest. Teams with an untrusted system register often start by checking AdapterCloud's live list against AssetHandler, teams facing a vendor audit or renewal season start with Subscriber Bot and AssetHandler's license tracking, and managed service providers often start with client review pages, which grow richer as each other product is connected.

Technical detail

Technical detail

Wherever the pain is sharpest. Teams with an untrusted CMDB often start with AdapterCloud discovery reconciled against AssetHandler. Teams facing a vendor audit or a heavy renewal season start with Subscriber Bot and AssetHandler licenses. MSPs often start with client review consoles, which grow richer as each other product is connected.

Related domains

Where these products also work together

All domains

Want to explore this for your organization?

Tell us about your setup. We will walk you through the products involved and scope a pilot around the challenge that hurts most.

Talk to usBrowse every domain

This is a solution concept: it shows how Burdenoff products are designed to work together in this industry. The images are illustrations of the concepts, not screenshots of the actual products, and every name and figure in them is sample data.