Most teams start with one person on Operations Workbench Starter, free for 30 days. Add LevelOneAI in Claude or ChatGPT, connect your email and add any exports you have, such as open POs or a schedule. Starter shows which changes put orders at risk, with the evidence, and tracks each one to a close. When the whole team needs it, with live ERP data, approvals and write-back, that's the Operations Workbench.

How do Starter, the Workbench and the Operations Engine fit together?

The LevelOneAI Operations Engine does the work: it treats each order, PO or job as one record (Work), compares what changed with what was promised (Context), works out what it affects and who needs to decide (Decision), and assigns, drafts and tracks the next step (Action), until it's resolved. Starter runs the engine on one person's email and the documents they add. A Workbench runs it across a whole team's email, ERP and CRM for one workflow, with live data, approvals and write-back.

Is there a free trial?

Yes. Operations Workbench Starter is free for 30 days, and you don't need a card. After that it's $199/month or $1,990/year (two months free), for 1 user and 1 mailbox. If you don't continue, your account becomes read-only and your data is deleted 30 days later.

What do I need to use Starter?

A paid Claude or ChatGPT plan (the free tiers don't include the access it needs) and a Gmail or Outlook mailbox. For work email, a business or enterprise plan from that provider is recommended. Documents are optional: exports from any ERP or spreadsheet work.

What's the difference between Starter and the Operations Workbench?

Starter works from one person's email and the exports they add, and you set it up yourself in minutes. It's built to show the value on your own work. The Operations Workbench connects live to your ERP and planning data, runs on its own, puts the whole team in one queue, and adds approvals, drafted follow-ups and write-back. Starter fees paid in the 6 months before you buy a Workbench are credited toward its setup.

Which documents should I add to Starter?

Whatever you have, or none. It works on email from the first run, and tells you which document would sharpen the results most. Typical ones are an open-PO export, a production schedule, open sales orders or an AR aging report. It keeps only the fields it needs from them, encrypted, never the files.

It says what it doesn't know. Each fact shows its source and when it arrived. When an email could match more than one order, it asks instead of guessing, and when a document is missing it says "impact not assessed" rather than "no impact." Your team makes the call.

How does billing work?

Starter is billed monthly or annually by card, with a receipt emailed for every payment and invoices on your billing page. Cancel anytime. A Workbench is a one-time setup fee, invoiced on the schedule in your quote, plus an annual platform fee that starts at go-live.

When does my team need a Workbench?

When the work depends on more than one person's inbox: the evidence sits in your ERP, CRM or planning data, several people need to see the same item, and someone has to make sure it closes. A Workbench gives the team one queue, one record per item, approvals and a team view.

What's built, and what do you configure for us?

The Operations Engine, the work queue, the work record, approvals, follow-up tracking and the team view are built. For each Workbench we configure the connections to your systems, the rules that decide what counts as an exception, who owns what, what closes an item, and whether approved changes are written back. Which systems it connects to, and how, is worked out during setup.

Operations Workbench Starter is free for 30 days, then $199/month or $1,990/year. An Operations Workbench is a one-time setup fee, from $20,000 per workflow, plus an annual platform fee that's included in your quote. There's no ongoing services fee: once it's live, your team runs it, and our help is optional. The platform fee covers hosting, AI processing, connector updates and improvements to the Operations Engine. It starts at go-live, and in the first year you can cancel 90 days after go-live if the agreed measures aren't met. The payback calculator compares the setup fee with what the delay costs you each year. The next Workbench reuses the connections you already have, so it costs less to set up. See Pricing for what's included.

How long does setup take?

Starter works the same day. A Workbench typically goes live in 6 to 12 weeks, depending on how many systems it connects and how complex the rules are. We agree the baseline and what success looks like before setup starts.

What happens to our ERP and CRM?

They stay where they are and keep the master data. A Workbench reads from them. Write-back is optional: whether approved updates go back, and to which systems, is decided during setup. Nothing changes in your systems without approval.

What data does LevelOneAI keep?

It's designed to keep only what it needs to run the work, such as references to the source, the facts it extracted (a date, a quantity, a price), status, owners and decisions. For a Workbench, exactly what's stored is agreed with you during setup. Starter never stores email: it keeps short labels, plus the fields it needs from documents you add, encrypted.

What will this ask of our IT team?

Starter needs no IT: you connect your own email in Claude or ChatGPT, and there's a one-page security summary to share with IT. A Workbench needs read-only access to the systems the workflow uses, granted once by whoever administers them, and typically a few hours of IT time during setup. Nothing is installed, and nothing changes in your systems without approval. See Growing Businesses if you don't have an IT department, or Enterprises for how we fit an IT review.

What happens when it isn't sure, or data is missing?

If an email could belong to more than one order or PO, it shows the candidates with their evidence and asks a person to confirm, instead of guessing. If a source is unavailable or a record can't be found, the item is marked incomplete, so your team knows the picture isn't complete. Every fact is labeled confirmed, conflicting, inferred or unknown.

Is this a product or a consulting engagement?

A product. The Operations Engine, the work queue, the work record and approvals are built. Setup configures them to your systems, rules and owners for one workflow. You pay a one-time setup fee and an annual platform fee. There's no ongoing services fee, so your team runs it without us.

Do you have a SOC 2 report?

No SOC 2 report yet. We'll walk your security team through the data flow and complete your security questionnaire on request.

What happens to our data if we stop?

You can export your work history and audit trail. With Starter, your data is deleted 30 days after you cancel or after a trial ends without a paid plan. Your ERP and CRM keep their own data, because they were the record all along.

That's decided with you during scoping, based on your security and IT requirements.

To read the messy information around a piece of work (the email, the attachment, the system field), match it to the right order or PO, compare it with what was promised, and recommend the next step. Every fact is labeled confirmed, conflicting, inferred or unknown, with its source. Your people make the call, and nothing changes in a system without approval.

Why can't we just add an AI agent?

You can, and it will do the steps. What an agent won't do on its own is keep one record of each order across email and your systems, notice a change nobody asked about, know which promise it breaks, and keep the issue open until it's resolved. That's what you'd have to build and maintain around it. LevelOneAI already does that, and works alongside the agents you use. See Why AI Agents Fail under Resources.

How is this different from process mining?

Process mining reads event logs from your ERP or CRM, so it can't see what happens in email, spreadsheets and phone calls, which is where most exceptions start. It also tells you where the process breaks; it doesn't work each exception to a close. A Workbench does.

Why not wait for our ERP or CRM vendor to add AI?

Use it. ERP AI is getting good at work inside the ERP, such as reading a supplier's email and proposing the PO change. A Workbench is for what happens next, across systems: which jobs and customer orders the change puts at risk, what the planner's sheet says, who has to approve, and whether it was actually resolved. If the problem starts and ends inside your ERP, its own AI may be all you need.

When is our ERP's own AI enough?

When the problem starts and ends inside the ERP, updating the record is the whole job, and everything the decision needs is already there. Add a Workbench when the change matters because of what it affects elsewhere (jobs, customer orders, invoices), when the numbers people trust live in a spreadsheet or portal, when resolving it takes several people and an approval, or when someone has to confirm it was actually resolved.

What if our workflow changes?

Rules, owners, thresholds and closing conditions are configuration, so they can be updated as your process changes, without a new project.

What if our team doesn't adopt it?

A Workbench brings the context to each piece of work instead of asking people to go and look for it, and it fits around the systems they already use. We also agree the measures up front, so you can see whether it's working.

All insights

General

Your Spreadsheet Isn't the Problem. The Work Behind It Is.

By Shanshan "Sasha" Ma

HubSpot is making external data usable inside the CRM, and that's the right direction. But a spreadsheet isn't always a data source — sometimes it's an unofficial application holding a workflow your systems don't represent. Data connectivity is not workflow transformation.

HubSpot is making a smart move.

It is increasingly letting data that lives outside the CRM — Google Sheets, Excel, other sources — become directly usable inside it: for segmentation, for reporting, and increasingly for triggering workflows and AI actions. Its workflow tooling can already fire on a change in a Google Sheet and run actions across HubSpot and third-party applications.

That is the right direction for enterprise software. But it raises a question the data layer can't answer on its own.

What if the spreadsheet isn't really a data source?

What if it's an unofficial application?

A sales team's spreadsheet might hold target accounts, deal priorities, pricing exceptions, implementation constraints, customer commitments, next steps, and internal approvals. At first glance the problem looks like data: we need to get this spreadsheet into the CRM.

Then ask the team why they maintain it. They use it to track work, reconcile information, decide what needs attention, assign ownership, manage exceptions, record decisions, coordinate with other teams, remember what happened.

The spreadsheet isn't holding information. It's holding a workflow the CRM doesn't fully represent.

Data connectivity is not workflow transformation

Two questions, two different problems:

The data problem: how do we get this information into HubSpot?
The workflow problem: why does someone need this information, what decision are they trying to make, what happens next, and which systems need to change as a result?

HubSpot is getting very good at the first one. LevelOneAI starts one level above it.

A concrete example

A company has a spreadsheet called Supplier Exceptions: PO number, supplier, promised date, required date, inventory, customer impact, buyer, status, escalation, notes.

They could connect that spreadsheet to the ERP. They could connect it to the CRM. They could expose it to an AI agent. The technology might work perfectly.

And the buyer still spends the morning looping ERP → Excel → Outlook → Teams → supplier portal → ERP → Excel: checking what changed, figuring out what matters, deciding who needs to act, and updating multiple systems by hand.

The spreadsheet was never the problem. The coordination work was.

So instead of moving the spreadsheet into another system, ask what the buyer is actually trying to accomplish. Maybe it is: resolve supplier exception #10492.

Now the experience can assemble the PO information from the ERP, the supplier's response from email, inventory from the inventory system, customer requirements from the CRM, contract terms from documents, and supplier history from prior transactions — one work item, one decision. Accept partial shipment. Request expedite. Find an alternate supplier. Escalate. The workflow then coordinates the actions across the systems underneath.

That is a fundamentally different proposition from making the spreadsheet easier to access.

But doesn't this create a new data problem?

This is the most legitimate objection to the whole model, and it deserves a precise answer. If you put an Operations Workbench between people and the systems of record, where does the data live now — and what happens when the two disagree?

The answer: the Workbench does not become a second system of record.

SAP owns the authoritative PO. Salesforce owns the authoritative opportunity. The ERP owns the authoritative inventory balance. The contract system owns the contract terms. The Workbench does not create competing truths for those fields. It assembles the context needed to do the work — some of it transient, some cached, some AI-generated — and it owns its own operational state: this exception is assigned to Jane. Approval is pending. Supplier follow-up is due tomorrow.

What it should never do is silently become the owner of "PO quantity = 1,000" when SAP is the authority for that field.

Our rule is simple: every authoritative field has one owner. LevelOneAI can display the customer name, the PO, the inventory balance, the contract terms, and the workflow status together. Displaying a value is not owning it. That is the line between an Operations Workbench and a shadow database.

Writes go back to the system that owns the truth

A workflow should never say "I updated the PO" when it only updated its own database.

The buyer chooses Expedite. The Workbench determines the governed write — update the supplier commitment in the ERP — sends it through the ERP's own API, and records the result. The ERP accepts or rejects the change. The ERP remains the authority.

That sounds like an implementation detail. It isn't. It is the architectural principle that keeps an Operations Workbench from becoming another source of truth.

And what happens when the API fails?

This is where many workflow promises break down. The user clicks Approve and update ERP. The interface shows Done. But the ERP API timed out.

Now what? If the workflow silently assumes success, you have created state divergence: the workflow says approved, the ERP says still pending. That is unacceptable.

So every important write gets a receipt — what action was requested, which system owns the result, the target record, the transaction identifier, the expected state change, whether the authoritative system confirmed it, and when it happened. And actions are idempotent: safe to retry without performing the same business action twice. On a timeout, the Workbench can answer: was the original request accepted, was it completed, can it safely be retried, does the source system already reflect the desired state?

That is what makes an Operations Workbench reliable rather than merely convenient.

Drift should become visible work

Even well-designed systems drift. Someone edits a record directly in Salesforce. An overnight ERP job changes a status. A supplier portal updates. An integration stops running. The Workbench may be holding an old representation.

So it has to check for divergence where it matters. The workflow believes the PO is awaiting supplier confirmation; SAP now says the supplier confirmed. Detect the discrepancy. Don't hide it. Don't overwrite SAP. Don't continue silently. Reconcile with the authoritative source, or surface the conflict as work someone owns.

Stale state in an operational workflow isn't a cosmetic problem — it's a financial and customer one.

Failure should be visible too

A failed automation is still a workflow state. Not "something went wrong" buried in a log only IT can read, but:

PO 45001234 — ERP update failed. Supplier expedite request was approved, but the ERP update could not be completed. Reason: API timeout. Current ERP state: unchanged. Next step: retry. Owner: Procurement Operations.

The person doing the work always knows the actual state of the operation. That is the difference between operational software and a pretty interface sitting on top of APIs.

And the IT maintenance debt?

The second-biggest objection, and a fair one: sounds great — now I have another custom system to maintain.

The goal isn't a bespoke application full of one-off integrations that only one consultant understands. It should be built from explicit contracts and reusable primitives: defined system ownership, governed API connections, reusable workflow patterns, standardized action interfaces, integration monitoring, audit trails, versioned workflows, automated health checks, visible failures, documented dependencies.

IT should inherit an understandable operating model — not another mysterious black box. And changing the workflow shouldn't mean rewriting the systems of record underneath it.

The distinction that matters

Bringing data together is not the same as bringing work together.

A spreadsheet can be a data source. It can also be a queue, a decision system, a handoff mechanism, an exception tracker, a memory system — an unofficial application.

If you only move the data, you may preserve the underlying work. If you understand the work, you may be able to eliminate the spreadsheet entirely.

System of record: what is true? System of work: what needs to happen?

The ERP stays the authoritative answer to what is the current PO? The CRM stays the authoritative answer to what is the current opportunity? The Workbench answers what needs attention right now, why does it matter, who needs to decide, and what should happen next? Complementary responsibilities, not competing ones.

Where AI becomes useful

AI doesn't need to become another database. It can operate inside the workflow — reading supplier emails, extracting dates and quantities, interpreting customer requirements, summarizing contracts, identifying discrepancies, assembling context, classifying exceptions, recommending next actions, drafting communications.

The workflow still governs state, ownership, business rules, permissions, approvals, and actions. The systems of record remain authoritative for their data.

AI interprets. Rules govern. Workflow orchestrates. People decide.

The bigger opportunity

The future of enterprise software isn't necessarily about replacing Salesforce, HubSpot or SAP — and it isn't about forcing every spreadsheet into them either. It's about making the work that crosses them actually executable.

Nobody should have to remember that the opportunity is in Salesforce, the PO is in SAP, the supplier's response is in Outlook, and the exception tracker is in Excel. They should be able to ask what do I need to resolve today? — and have the system assemble the context, surface the decision, coordinate the action, and leave the underlying systems consistent with what actually happened.

The systems of record keep the truth. The Workbench makes the truth useful.

Not another database. Not another CRM. Not another integration tool. A system of work for the workflows that fall between your systems.

Your systems stay. Your people stop being the integration layer.

Talk to us