--- title: "AI Technical Support: Response From 4 Hours | JustAutomate" description: "Support after go-live: monitoring with alerts, response from 4 hours, a metrics review every quarter, new processes added without rewriting what runs." url: "https://justautomate.ai/en/services/ai-technical-support/" lang: en --- Advisory, training and support # AI technical support for your automations so you see the failure before your customer Automation is not set and forget. A vendor ships a new API version, a token expires, a supplier renames the columns in a file, a model gets a new release. We watch that for you: monitoring with alerts, response from 4 hours, a metrics review every quarter, new processes added without rewriting what already runs. Support is optional, because the documentation and the access are yours from day one. Book a free consultation [See how the workshop works](https://justautomate.ai/en/services/process-workshop/) - 4 hoursresponse time on a critical failure during working hours. On the dedicated plan, 2 hours - 90 dayshow long an access token lasts in some integrations. The flow stops even though nobody changed the logic - 30 and 90 dayswhen we measure the first numbers after go-live. After that, a review every quarter The problem ## Why does an automation that ran for a year stop on a Wednesday? The flow ran for seven months without a single ticket. Then the CRM vendor shipped a new API version, and the field that used to hold the deal stage came back under a different name and a different data type. The scenario still fired and still finished with a green status, it just wrote empty records. The company found out from a customer who asked why nobody had answered his request from the week before. Things that break on their own are predictable, which is exactly why they can be watched. Vendors retire old API endpoints and change response structures. An access token expires because that is how authentication works, not because somebody made a mistake. A supplier sends a file with a renamed column. A model gets a new version and the old one stops being available. Volume grows and you start hitting the rate limit at peak hours. The law around the solution moves as well. [Regulation (EU) 2024/1689, the AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), entered into force on 1 August 2024, most of its provisions apply from 2 August 2026, and part of the obligations for high risk systems embedded in products start on 2 August 2027\. A solution launched today runs under law that is still closing, and somebody has to track that instead of assuming that compliance set once stays set forever. - An integration has been down for three days and you hear it from a customer - Nobody in the company knows what you pay this month for operations in Make or n8n - The person who built it has left and outside that person nobody understands it - The next process waits in the queue, because you are afraid to touch something that somehow works Why now ## What changed, so a failure shows up in minutes instead of a week later? Automation tools now say for themselves when something did not go through. n8n and Make have a separate error workflow that fires on a failed execution and can push the error text to where the team already looks: Slack, Microsoft Teams or email. Error handling and retry behaviour are written up openly in the [n8n documentation](https://docs.n8n.io/) and in the [Make help centre](https://www.make.com/en/help/). It used to take opening a panel to see a red line in the log. The second change is the cost of monitoring. Checking tokens, rate limits and operation counts does not have to be somebody's Saturday, because it is itself a process that can be automated. You pay for people's time when something has to be fixed or changed, not for watching. The third thing is the AI agent. An alert says something broke, but it will not answer the question which processes stopped this month and how many times. BOND, our company AI agent, answers that in a plain sentence in 5 to 10 seconds, without logging into three panels. A BOND rollout takes around 2 months and is a separate decision, not a condition of support. What changes ## What do you get once it is running? - ### You see the failure before your customer does Every failed run goes into the error workflow, and from there an alert lands on Slack, in Teams or in the inbox. The alert carries the process name, the error text and the moment it broke. An alert within minutes of a failed run, instead of a complaint a week later - ### A response with a deadline, not with good will A critical failure, meaning one that stops sales, invoicing or customer service, has a response time from 4 hours during working hours. On the dedicated plan, 2 hours. We promise RESPONSE time, not repair time: a failure on the vendor side is not ours to control - ### A vendor change does not take the flow down On a fixed rhythm we go through logs, token expiry dates, rate limits and notices about retired API versions. A fix is tested on test data before it reaches production. Token rotation written into the review calendar, not left to chance - ### Tool cost stays under control Once a quarter we count operations in Make or n8n, model queries, and whether the plan still fits your volume. Redundant steps in a scenario cost money every month until somebody removes them. You pay the vendors directly, model queries at EUR 0.005 to 0.07 each, with no margin from us - ### The next process without rewriting everything Small changes, a new field in an integration, an extra notification, a corrected condition, run inside the support scope. A new process is added to the existing structure instead of a second set of scenarios built next to it. No separate project and no new quote for every small change - ### The solution stops being a black box Scenarios, access and documentation sit on your side from the first day. Your technical person knows where to look, what they can change alone and when it is better to call. Support is optional: you can run the solution yourself and it will keep working Proof ## Do you watch your own processes this way? Yes. Monitoring inside our founders' agency is run by an AI agent, the same one behind the numbers on our AI for business page. Below is the scale of that work, together with what the number does NOT prove. Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof. - ![JustIdea Agency](https://justautomate.ai/klienci/justidea.png)![JustBot](https://justautomate.ai/agenci/justbot-80.webp)JustBottheir agent JustIdea Agency, a performance marketing agency of around 30 people 23 people from the company work with the agent 38 systems wired in permanently 112 processes run without a human 475 thousand lines of the agent’s code The agent is wired into client site monitoring, the data warehouse, the ad accounts and Slack. It watches the things that have to be checked without a break and that nobody wants to check by hand. 8 of 38 systems it works in - Google Ads - Meta Ads - HubSpot - ActiveCollab - Ahrefs - GA4 - Search Console - BigQuery Before A site outage or a broken warehouse load was caught by a person who happened to open a panel. Between one look and the next, nobody was checking at all. After Checks run on a fixed rhythm with no person involved, and the team gets a signal only when something did not go through. A person steps in to fix, not to watch. 4,354 monitoring checks and 3,506 operations against the data warehouse in 30 days, run without a person And in your company ## What if you want to maintain it yourselves? That is a normal scenario and we say it plainly: support is optional. Four sentences we hear most often, and what we answer to them. - We do not want to be tied into another subscription. You do not have to be. The solution runs on your accounts, the scenarios and the documentation are yours, and training closes the rollout whether or not you take support. You can run it yourself and come back to us only when a change turns up that you would rather not make with your own hands. - We have our own IT, they will maintain it. Usually they will, and we will tell you so. In that case we leave the monitoring behind, plus a failure playbook with the steps to follow, and we hand the knowledge to your technical person. The scope that makes more sense then is second line support: we step in on vendor changes and on expansion, while the daily watching stays with you. - Somebody else built these automations, not you. We take over other people's flows, but we review them first: what they do, what they stand on, where there is no error handling, and in whose name the access is issued. If it turns out that rewriting part of it is cheaper than maintaining it, we say so with the reason, instead of charging for support on something that cannot be kept alive. - We do not know how many hours we need. Nobody knows that at the start. We begin with the smallest scope that makes sense, count the real tickets and the time they took through the first quarter, then move the scope up or down. Overpaying for hours you never use is not in our interest, because after a year you would walk away from it anyway. Automation layer n8n, Make, Zapier, custom API integrations CRM HubSpot, Pipedrive, Salesforce, LiveSpace Accounting and invoicing Fakturownia, iFirma, sevDesk, Xero, Comarch Optima Sales BaseLinker, Allegro, Shopify, WooCommerce, PrestaShop Team work Google Workspace, Microsoft 365, Slack, Notion, ClickUp, Jira, Asana Data and reporting BigQuery, Google Sheets, GA4, SQL databases ## What breaks on its own, and how you notice The most common cases from our practice. The right hand column says what support does in that situation, so you can hold it against what happens in your company today. | What changes | What you see | What support does | | ----------------------------------------------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------- | | A vendor ships a new API version | the flow finishes with a green status but writes empty fields | a test on test data and a mapping fix before production | | An access token expires, after 90 days in some integrations | the integration stops answering although nobody changed the logic | expiry dates in the review calendar and rotation ahead of time | | A supplier renames the columns in a file | the import fails or writes data into the wrong fields | file validation and an alert instead of nonsense saved quietly | | A model gets a new version, the old one is retired | answers stop matching the required format | a test on the same 20 examples and a decision on the version | | Volume grows and you cross the rate limit | some runs fail at peak hours | queuing, retries and a recount of the limit with the vendor | | The tool changes its pricing or its plan | the bill grows although the process is the same | an operations count once a quarter and cuts to redundant steps | | The person who knew the process leaves | nobody knows what that scenario does or whether it can be switched off | documentation, a failure playbook and handover to a new person | Which of these rows applies to you comes out in the review, because it depends on what your flows stand on and how many of them touch money. How we do it ## Five steps from a silent failure to a process that reports itself Every step ends in something you can judge before you decide on the next one. 1. ### A review of what already runs We write down the flows, the integrations, the access and the places with no error handling. We read the logs from the last few weeks and the tool invoices, because that is usually the moment it comes out how many processes fail regularly with nobody reporting it. 2. ### Monitoring and alerts Error handling goes into every flow, and out of it an alert to Slack, Teams or email. We agree with you what counts as a critical failure and what is a small item for the queue, so that the team does not stop reading notifications after a week. 3. ### A maintenance rhythm A fixed cycle: logs, token deadlines, rate limits, notices about retired API versions, fixes after vendor changes. Small changes raised by your team run in the same rhythm, without opening a separate project. 4. ### A review every quarter Once a quarter we sit down with the numbers: how many processes failed, how many times, how long it took from alert to fix, what you pay for operations and models. Out of that comes a list of things to improve and a decision on which process to automate next. 5. ### Handover of knowledge Documentation, failure playbooks with the steps to follow, and training for your technical person. The goal is plain: if you wanted to end support, the solution has to keep running and you have to know where to look. Before and after ## How the week changes for the person who owns operations ### Before - Hears about a failure from a customer or a salesperson, days after the fact - Does not know how many processes fail in a month, because nobody counts them - The tool bill grows and there is nobody to ask about it - Puts off expansion, because touching something that somehow works feels risky ### After - An alert arrives within minutes of a failed run, with the process name and the error - Once a quarter sees the numbers: how many failed, how long it took, what it cost - Vendor changes handled before they take a flow down in production - Adds the next process to the existing structure, inside the support scope Monitoring and alerts work from the first days. Maintenance numbers start to mean something after 30 and 90 days, because only then can you tell what fails regularly from what failed once. For the person who signs this off ## What the owner or the operations director gets out of it Risk stops sitting in one person's head. Today the continuity of your processes depends on whether a particular person opens a panel, and on whether that person still works here at all. Once support is in place it depends on monitoring, documentation and an agreed response time, things you can check without a conversation with that person. The second point matters more in a budget conversation. You know how many processes failed in the quarter, how long it took from alert to fix and what you pay for tools. That is an argument for expanding or for letting go, and today you do not have it, because nobody collects those numbers. - Response time from 4 hours on a critical failure, 2 hours on the dedicated plan - Access, scenarios and documentation on your side, not on ours - Support optional and cancellable: the solution runs on without us - A quarterly report with numbers, instead of a feeling that it probably works What it costs ## The workshop has a published price, support is quoted after it The process workshop costs **EUR 3,500 net per week**, 1 to 7 weeks. Reviewing automations you already run usually takes a single week, because the scope is narrow: what you have, what fails and what nobody watches. Support is quoted after that review, once it is clear how many flows are in scope and how many of them touch sales or invoices. Tool and model cost goes to the vendors directly, with no margin from us: n8n, Make, Zapier, the model provider. Model queries run at EUR 0.005 to 0.07 each, depending on the model and the length of the question. If the automation sits on your own infrastructure, you pay nothing for it at all. So you see two separate lines: the vendor invoice and our scope of work. - ### Process workshop EUR 3,500 net per week, usually one week when the job is reviewing automations you already run A closed piece of work. It ends with a list of what breaks in your company and a maintenance plan you can defend without us. - An inventory of flows, integrations and access - A list of places with no error handling and no monitoring - A review of tool cost and operation counts - A maintenance plan split into what you do and what you outsource Start with the workshop - Most popular ### Workshop and post-rollout support Quoted after the workshop the scope follows the number of flows and how many of them touch money The most common choice. Monitoring with alerts, an agreed response time and small changes inside one scope. - Everything from the workshop - Error handling and alerts to Slack, Teams or email - Response from 4 hours on a critical failure during working hours - Reviews of logs, tokens and rate limits on a fixed rhythm - Small changes without opening a separate project - A review of metrics and tool cost every quarter Talk to us about support - ### Support and an AI agent Quoted after the workshop for companies where several people a day ask about the state of the processes Everything from support plus BOND, the company AI agent that answers questions about the state of your processes in a plain sentence. - Everything from post-rollout support - BOND wired into your data, an answer in 5 to 10 seconds - Questions about process state without logging into panels - Response time of 2 hours on a critical failure Ask about the agent The workshop ends in a document you can defend without us: a maintenance plan split into what your IT does and what an outside team does. If the review shows your own people can keep it running, we say so and we do not sell you support. Support is optional and cancellable, and the solution sits on your accounts, so ending it stops no process. ## Frequently asked questions What is technical support for automation and AI? It is an ongoing service that starts once the solution is live. We monitor the flows and integrations, respond to failures within an agreed time, run reviews of logs, tokens and rate limits, make small changes without a separate project, and once a quarter sit down with the numbers together with you. It is not the same as a rollout: a rollout has an end, support is a rhythm. Is post-rollout support mandatory? No. The solution runs on your accounts, the scenarios and the documentation are yours, and training closes the rollout regardless of what you decide about support. You can run it yourself or hand it to your own IT, and come back to us on a change you would rather not make alone. Support is convenience and a split of risk, not a condition of the thing working. What is the response time on a failure? From 4 hours during working hours on a critical failure, meaning one that stops sales, invoicing or customer service. On the dedicated plan, 2 hours. We promise response time, not repair time, and we say that openly: when the failure sits with the vendor or with their API, we can put a workaround in place and escalate the ticket, but we do not control the date of their fix. What exactly does the monitoring measure? Failed flow executions, errors returned by integrations, token expiry dates, rate limit breaches and the operation count that turns into your invoice. The alert goes where the team already looks: Slack, Microsoft Teams or email. We set the thresholds with you, because monitoring that raises an alarm over every small thing stops being read after a week. Will you take over automations built by somebody else? Yes, after a review. We check what they do, what they stand on, where they have no error handling and in whose name the access is issued, because a scenario hanging off a former employee's account is a delayed charge. If maintaining it works out more expensive than rewriting part of the flows, we say so together with the reason. What happens when a vendor retires a model version or an API endpoint? We catch the retirement notice during a review and plan the change before the deadline, rather than on the day of the failure. A new model version is tested on the same examples as the old one, to see whether the answers still match the required format. On an API we fix the field mapping on test data first and only then go to production. Can another process be added inside the support scope? Small changes, a new field in an integration, an extra notification, a corrected condition, run inside support. A larger process is a separate scope, but we add it to the existing structure instead of building a second set of scenarios next to it. Expanding does not mean rewriting everything, because we lay it out from the start so that things can be added. What if we want to end support? Nothing stops working. The accounts, the scenarios and the data are yours from the first day, and the documentation and failure playbooks stay with you along with the training recording. On exit we hand over the state of the monitoring and a list of the things that have to be watched from then on, so that the knowledge does not leave with us. ## Let us find out what breaks quietly in your company The free consultation takes 30 minutes. You tell us what automations you already run, who built them and how you find out about a failure today. We show what can go under monitoring straight away and where error handling has to go in first. You do not have to share any systems at this stage. We run at most two rollouts at a time, so that someone is genuinely sitting on each of them. [Book a free consultation](https://justautomate.ai/en/contact/) **PS.** If you heard about your last failure from a customer, that is exactly this problem. A process nobody watches fails quietly and finishes with a green status, and one week of that silence can cost more than a whole quarter of support. You write directly to Paweł, with no helpdesk and no tickets. ## Related - [n8n automation](https://justautomate.ai/en/services/n8n-automation/) - [API integration](https://justautomate.ai/en/services/api-integration/) - [BOND, business AI agent](https://justautomate.ai/en/services/bond-business-ai-agent/) - [AI consulting](https://justautomate.ai/en/services/ai-consulting/) - [AI training for business](https://justautomate.ai/en/services/ai-training-for-business/) - [Process workshop](https://justautomate.ai/en/services/process-workshop/) --- **JustAutomate** · contact: contact@justautomate.ai · form: https://justautomate.ai/en/contact/