AI automation solution with setup and support

An AI automation solution with setup and support includes a working configuration and explicit agreements on monitoring, error handling, recovery, software changes, model replacements, new tasks, and handover when the provider leaves.

The decisive question starts after launch: who notices unfinished work, who fixes it, and what do you pay? Below, public support terms sit alongside the agreements you need for your own process. Vendor figures are contract terms or product descriptions, rather than independently measured performance.

The short answer

• Setup, technical support, and guidance on new tasks are separate services. Microsoft generally excludes instructor-led training from its support plans. Microsoft, accessed September 30, 2026.
• Microsoft lists an initial response within one hour for critical Power Platform incidents, conditional on continuous customer availability. This is not a recovery deadline. Microsoft, September 30, 2026.
• Make publishes 99.5% availability for Enterprise. Mathematically, 0.5% of a 30-day month equals 3 hours and 36 minutes. The contractual measurement method determines what counts. Make, September 30, 2026.
• Make disables storage of incomplete executions by default. Someone must actually configure recovery facilities. Make, September 30, 2026.
• Anthropic gives at least 60 days’ advance notice before retiring publicly released models. Model maintenance therefore belongs in ongoing management. Anthropic, September 30, 2026.
• A transferable configuration includes work instructions, rules, outstanding work, and access agreements alongside data. An export file alone does not prove a successful handover.

What should setup and support include?

A complete offer describes what works at delivery and who keeps it working afterward. “Included” only means something when you know which tasks, systems, and changes it covers.

At delivery, request a short description of the agreed process: what arrives, what is prepared, who approves, and where does the result appear? Include examples of ordinary work, missing information, and an interrupted execution. You can then decide later whether something is an error or a new request.

Use this division for service agreements. It is a purchasing framework, rather than an established market standard.

The division at the start is covered in more detail under implementation and guidance. This page concerns the months afterward. The existing guide to AI without an IT department describes the role your own people retain.

Which SLAs do vendors actually publish?

Read an SLA, a service level agreement, by product, subscription, and incident type. These examples represent different parts of an automation chain. AFAS, Dutch business software, supplies the business package. Make and n8n supply automation software. Microsoft describes support for Power Platform. They do not form a ranking of complete providers.

Sources, all accessed September 30, 2026: AFAS, sections 2.2 and 2.3, Microsoft, Make, and n8n. These are the sellers’ own publications.

Especially when an agency works on top of such a product, you need to know who receives and forwards your report. An automation subscription does not prove that someone monitors your invoice stream. Ask the solution provider to name who owns follow-up, even when another vendor performs the technical repair.

How much downtime does 99.5% or 99.9% availability mean?

Availability percentages only mean something when you know the measurement period and exclusions. These times are our calculations for an uninterrupted 30-day month: 43,200 minutes multiplied by the downtime percentage. They are neither measured outages nor predictions.

The 99.5% matches the AFAS and Make publications mentioned above. The other percentages are comparison values. Planned maintenance excluded from measurement may make actual unavailability longer than this table suggests.

You also cannot apply one vendor’s percentage to the whole chain. Suppose four required services each truly have 99.9% availability, their outages occur independently, and there is no fallback. Combined availability is then 0.999⁴ = 99.6006%, about 2 hours and 53 minutes of downtime per 30 days. This is a theoretical model. Shared outages, queues, and recovery facilities change the result.

For your administration, what ultimately counts is how much work arrives correctly and on time. A temporary outage need not mean a missed invoice if the task is safely stored and executed later. Conversely, everything can be available while an invoice goes to the wrong file.

What should monitoring check after launch?

AI automation monitoring must reveal technical errors, unfinished work, and substantively unusual results. Checking whether an application is accessible does not tell you whether your administration is correct.

Request an overview that reconciles incoming, completed, and outstanding work. A useful check is: opening backlog plus new tasks minus completed and deliberately canceled tasks must equal the closing backlog. Specify whether a task is only complete after processing in the target system. A created proposal is not yet a processed entry.

Also show the age of outstanding work. Distinguish waiting for an employee, missing information, and technical failure. The oldest untreated case is often more useful than average turnaround time alone. An average hides precisely the work left waiting.

Substantive review needs a different measurement. Track how many proposals of each task type were changed or rejected, why, and which configuration version was active. Distinguish, for example, the wrong customer, wrong amount, and wrong next step. A rising correction rate warrants investigation. It does not automatically prove the model has deteriorated; the incoming work may have changed too.

Finally, agree who responds to each signal. An error message without an owner is just extra mail. How employees assess proposals is covered in errors and review.

What happens when an execution fails halfway through?

Support must establish which steps already happened before restarting work. Otherwise you risk duplicate results: creating the same order again or sending the same message twice.

Make illustrates why “automatic recovery” needs explanation. Storage of incomplete executions is disabled by default. When enabled, Make can store unfinished work for resumption. Make, September 30, 2026.

For certain temporary errors, Make publishes 8 retries, scheduled at 1, 11, 21, 51, 81, 111, 291, and 471 minutes after the original execution. At most 3 such retries run simultaneously per scenario. This schedule does not promise that your case will be complete within 471 minutes. Make, September 30, 2026.

A retry also uses the same settings as during the error. A temporary connection failure may disappear this way. An incorrect setting needs a change. Make, September 30, 2026.

During setup, therefore ask for an interruption demonstration: the target system receives the order, but its confirmation never returns. Can the solution find the existing order before writing again? Can an employee see which cases remain uncertain? This is a more concrete recovery test than merely triggering an error message. The full testing approach is in testing an AI agent before automating.

Which response and recovery agreements make sense for your business?

A suitable support agreement starts with what downtime means for your process. Updating an internal file has a different deadline from an order that must reach a technician today.

Record separately when the vendor detects the outage, when someone responds, when safe work can resume, and when the backlog is cleared. Also state whether the clock runs outside office hours and what happens when connected software causes the problem. Ask what missing a deadline produces: a discount, escalation, recovery plan, or another contractual consequence.

For data recovery, also ask about two separate goals: how quickly can the service operate again, and how much recent work may be lost during recovery? These are often called RTO and RPO. A restored copy may predate the last approval or message sent. The recovery test must therefore also show how already executed actions are compared with the restored records, so nothing disappears or happens twice.

Our own calculation illustrates the difference. Suppose 40 tasks arrive per hour. Two hours of downtime create a backlog of 80 tasks. After recovery, the solution processes 60 tasks per hour while 40 still arrive. The net backlog reduction is 20 tasks per hour. Clearing it takes another 4 hours: 6 hours after the outage began. All figures are assumptions, rather than customer results.

Our position: buy recovery of your backlog, alongside software availability. The SLA times above and Make’s bounded retries together explain why. A quick response and a working server do not tell you when your administration is up to date again. For a small or midsize business team, that is the useful service agreement.

Who pays for software changes and new tasks?

The quote must distinguish restoring agreed behavior, maintenance prompted by external changes, and expanding the work. Without this division, every change gets a different name and price afterward.

An error in an existing customer connection differs from connecting another set of accounts. A changed field in accounting software differs from deciding to process a new document type. Put these examples alongside the fixed price. Ask the vendor what is included, which usage limit applies, and when a quote will be provided in advance.

Existing products also show that support does not automatically cover development or advice. n8n lists €667 per month with annual billing for its self-hosted Business subscription, with forum support. Dedicated support is listed under Enterprise, by quotation. The license price alone therefore says too little about the help you buy. n8n, September 30, 2026.

A scheduled test helps with updates. AFAS describes AFAS Accept as a separate test environment where you can run existing processes before a new version’s release date. This provides preparation time. It does not guarantee that your external automation has already been tested. AFAS, September 30, 2026.

Record who reads release notices, what is retested, and who authorizes a changed working method. Connection ownership is discussed further in an AI agent platform with integrations.

What happens if the AI model changes or disappears?

A model replacement belongs in AI solution maintenance, with an owner, a test, and a decision on deployment. Better scores on general tests do not prove a new model treats your exceptions the same way.

Anthropic states at least 60 days of advance notice before retiring publicly released models. Requests to a retired model fail. The documentation therefore recommends testing replacements on your own application well before the deadline. These dates apply to the named Anthropic platforms. Other distribution channels may have their own schedules. Anthropic, September 30, 2026.

Keep examples with known correct outcomes for that test: an ordinary request, a duplicate document, missing data, and a conflicting agreement. Compare the selected customer, amounts, sources, and required approvals. A differently worded sentence matters less than a changed action.

Ask whether business rules and previous corrections are stored separately from the model. Also record what happens if the test result is inadequate. Switching back only works while the old model remains available. After that, you need a tested replacement or a manual work route. A fallback model must not silently receive broader permissions. The boundary for sending email after approval must remain in force during an outage too.

What if the vendor stops or you want to switch?

A usable exit plan must give your business access to its work and knowledge without daily help from the original vendor. Agree on this while the vendor is still available.

Distinguish an automation agency closing from the disappearance of the software service it uses. If only the agency stops, a successor can sometimes manage the existing configuration. If the underlying service stops, the process must run elsewhere. That requires more than another consultant’s phone number.

Request handover of these components:

• Your own documents and data, plus the status of outstanding and partially executed tasks.
• The work instructions, decision rules, exceptions, corrections, and approvals that explain the process.
• The configuration and test examples, with sufficient usage rights for a successor to work with them.
• Access controlled by your business, with a procedure for revoking the departing party’s accounts.

Make provides a concrete example of why export is not a working handover. A blueprint contains modules, settings, and field mappings and can be exported as JSON. After import, you must recreate connections to your own accounts. Make, September 30, 2026.

Practice a handover before depending on an exit clause. Check whether someone else can perform a sample task and recognize affected work. Also ask about retention periods, deletion, transfer costs, and access if the vendor suddenly becomes unavailable. A promise to help later is weaker than a usable copy you already control.

Where is this heading?

Our expectation: by the end of 2027, demonstrable management of changes will become a more important purchasing criterion for AI automation than a short support response time alone. This is a hypothesis about purchasing behavior, rather than a measured market development.

The pace of model replacement is visible. The Anthropic list examined contains 7 retired model IDs on 5 different end dates between January and August 2026. This is our count of one vendor’s list, rather than an average lifespan. Anthropic, September 30, 2026.

Compare that with the software updates described earlier and the difference between restoring software and clearing backlogs. As more tasks depend on one solution, one change affects more work. We therefore expect buyers to demand evidence: which tasks were retested, which outcomes changed, and who authorized release?

This expectation fails if vendors make changes fully compatible with existing applications for a long time, or if businesses mainly keep AI for standalone drafts. The consequences of changes then remain smaller.

For Bombos, the development direction is to preserve your rules and corrections while the model changes. Our ambition for the end of 2027 is to handle that transition for your team with demonstrable checks on existing tasks. This is a development ambition, rather than a current SLA or delivery guarantee.

What can support for AI automation not guarantee?

Support cannot guarantee error-free content or uninterrupted operation of every vendor involved. An approval step helps catch errors, but an employee can approve an incorrect proposal. A recovery procedure cannot undo a sent message at the recipient’s end.

This comparison also has limits. Published terms do not prove how quickly help desks actually respond. We have not performed an identical incident test at these vendors. A contractual percentage is not measured performance, and the calculations on this page are not customer results.

The public Bombos product texts examined do not specify support hours, incident priorities, or recovery deadlines after the pilot. They also contain no detailed handover arrangement. Guidance during the pilot does not prove those agreements. If you have a firm 24/7 requirement, these texts cannot establish that Bombos meets it.

The practical boundary is clear: assess the product by what is described and demonstrated, and the service level by explicit written agreements. Do not fill in missing terms favorably yourself.

How does Bombos approach this?

Bombos sets up the first task with you and guides you during the pilot, so you do more work, at a higher quality, with the same team. Chef distributes incoming work. Wegwijzer helps you get started. Specialists are built around your tasks, systems, and rules.

Bombos reads what arrives, finds the customer and file, and prepares a supported proposal. You approve, change, or reject in Bombos. After approval, the result goes into the connected software. Payments, customer messages, and contracts wait for your approval by default. This boundary is technically enforced. You cannot turn it off yourself. Only Bombos can do so at your request, at your own risk.

Corrections become rules for subsequent proposals, including for coworkers. Bombos records knowledge that only exists in someone’s head by interviewing your people. What Bombos learns resides in those recorded approvals and corrections. The model is a replaceable component.

The pilot costs €2.000 for three months, with guidance from the makers. Afterward, Bombos costs €1.000 per month, the same for everyone. The product description also mentions management in consultation with your software vendor or administrator. That price and guidance do not create an additional promise about incident deadlines that have not been agreed. Bombos, product texts accessed September 30, 2026.

The first task is the beginning. Afterward, your own team teaches Bombos the next task by explaining how you work and improving proposals. We guide you, then you can do it yourself.

Sources

Each source was opened on September 30, 2026, and each original quotation appears verbatim in it. Short source excerpts appear below for checking. Dutch excerpts are labeled as translations. AFAS, Microsoft, Make, and n8n sell the software discussed; Anthropic sells the models discussed. Their documentation describes their own terms and features, rather than independent performance measurements. The two Bombos sources were read in the supplied local website source. A live recheck through the web tool was unsuccessful.

1. AFAS, AFAS Profit SLA, January 2026. Opened September 30, 2026. Sections 2.2 and 2.3, translated: “Availability of 99.5% per month is our minimum.”
2. Microsoft, Support for Microsoft Power Platform and Dynamics 365 apps. Opened September 30, 2026. “Standard: Less than one hour”.
3. Make, Security and compliance. Opened September 30, 2026. “99.5% Cloud Service Uptime”.
4. n8n, Plans and Pricing. Opened September 30, 2026. “Dedicated support with SLA”.
5. Make, Incomplete executions. Opened September 30, 2026. “Incomplete executions are disabled by default.”
6. Make, Automatic retry of incomplete executions. Opened September 30, 2026. “a limit of 3 incomplete execution retries running in parallel”.
7. Make, Manage incomplete executions. Opened September 30, 2026. “The incomplete execution runs with the same module settings as when the error happened.”
8. Anthropic, Model deprecations. Opened September 30, 2026. “at least 60 days’ notice”. Our count uses the Model status table and deprecation history on that page.
9. Make, Scenario blueprints. Opened September 30, 2026. Contents include “Module settings” and “Mapped values”.
10. Bombos, homepage offer. Local source src/i18n/home.ts, accessed September 30, 2026, translated: “the makers guide you for three months in using it”. Our own product description.
11. AFAS, AFAS Accept. Opened September 30, 2026. Description: a separate test environment for running existing processes before a new version’s release date.
12. Bombos, How do I use AI without an IT department?. Local source src/data/gidsen/zonder-it-afdeling.ts, accessed September 30, 2026, translated: “Your team teaches the next task itself.” Our own product description; supplied writing rules take precedence over older wording.