What Isovel won't compromise on

Most marketing pages are positioning. This one is architecture. Below are seven things Isovel will not compromise on — they’re written into the product before the marketing copy. If we ever break one, hold us to it.

1. Time-to-first-insight under 10 minutes

From “click connect” to first actionable recommendation, on a clean BC environment, in under ten minutes. Not “during onboarding.” Not “after data cleanup.” In the first ten minutes.

This is the whole product promise. Any feature that requires a planner to “configure” something at onboarding violates it. Any sales motion that starts with “schedule a call to scope the engagement” violates it. We measure it; we publish it; we miss it sometimes; we don’t hide when we miss it.

2. Zero setup is literal

Zero, not “minimal.” No forecast hierarchy configuration. No ABC tagging by humans. No lead-time entry. No promo calendar maintenance. No expression-authoring. No “service-level target” tuning workshop.

If the agent needs to know an ABC class, it derives it. If it needs lead times, it pulls them from BC. If it needs a promo signal, it detects the anomaly. If it can’t, it tells you it can’t and shows what it would assume otherwise.

This rules out a lot of useful features. We accept that.

3. 30 days. Read-only. Shadow mode.

Trial is read-only. For thirty days, Isovel pulls your BC data, builds dashboards, surfaces recommendations — and never writes to BC. You can compare its recommendations against your own. You can ignore them. You can override them. The agent doesn’t touch a single record.

Write-back unlocks at conversion to paid. Not before.

This is how we get past the IT director. It’s also how we make trial-to-paid a clean upgrade narrative: “We’ve shown you the recommendations for thirty days. Ready to let us act?“

4. Trust primitives are permanent. Autonomy is graduated.

Every write-back to Business Central is approval-gated by default at launch, idempotent (re-runs never duplicate writes), reversible inside a 24-hour rollback window, and audit-logged.

The trust primitives — pause, kill, rollback, restore-manual-approval — are permanent architectural commitments. They never go away. The agent’s autonomy is graduated: as you gain comfort with its track record, the default-required-approval-per-action loosens step-by-step. Transfer orders below a threshold may auto-execute after thirty days of correct recommendations. But the planner can always restore explicit approval, pause the agent, or roll back any action.

We don’t say “fully autonomous” and we don’t say “lights-out planning.” Those frames are wrong for an ERP write-back agent. “Transparent, auditable, and reversible” is the canonical trust vocabulary. Anything else is overclaim.

5. Sales-less is the architecture, not a marketing tactic

We have two teams: marketing and engineering. There is no sales team and there will not be one.

Pricing lives at /pricing/, not behind AppSource and not behind a contact form. Direct-priced. Self-serve. If a prospect needs a live demo to convert, that is a failure of the website. The website does the persuasion work — the demo videos, the product walkthrough, the comparison pages, the trial flow.

This rules out partner-channel revenue. We accept that. The mid-market BC distributor we serve doesn’t want a partner-mediated planning purchase any more than they want a six-figure implementation.

6. Never overclaim AI accuracy

We will publish real forecast-accuracy benchmarks when we have customer data to publish. Until then, we will not cite headline accuracy numbers — neither our own nor other vendors’.

Operator skepticism on vendor accuracy claims is well-earned. “In over two years we never received a demand planning software that was over 50% accurate when compared with actual,” a ten-year demand planner posted on r/supplychain. We treat that as a baseline, not a marketing problem.

If we ship a forecast and it misses, we tell you it missed and we re-tune. The confidence band is the contract. The headline number is not.

7. Microsoft-complementary, never Microsoft-adversarial

Isovel is built on top of Microsoft Dynamics 365 Business Central. We need Microsoft’s BC partner team and AppSource on our side. We need the BC distributor community to read this page and not flinch at how we talk about Microsoft.

We do not say “Microsoft walked away,” “Microsoft abandoned X,” or “Copilot can’t.” We say Isovel is the AI-native planning layer that complements Microsoft’s BC roadmap. Where there’s a structural gap (BC’s planning worksheet doesn’t reason across multiple locations; the EFW worksheet is single-location), we name it factually — and we name our fix factually — without sniping.

Microsoft Copilot answers questions about your BC data. Isovel decides and acts on it. Both can coexist. The framing is “and,” not “instead of.”

Why this page exists

Most non-negotiables in software end up bargained away two product cycles in. We’re putting these on the record so that when an enterprise prospect asks for the customization, when a sales-less posture fails to close a $300K deal, when an AI hype cycle pressures the accuracy framing, you can show us this page back and ask which one we broke.

We expect to defend these for years. If we ever update them, we’ll log the change in this page’s version history and explain why. Don’t take the silent edit.

Get early access