From waiting to looking ahead: why we shifted to a proactive approach for Business Central support

For a long time, support worked for us as it does for almost any ERP partner: a report comes in, we address it, we solve it. That works, but it has one major drawback. By the time a user calls or creates a ticket, they have already been inconvenienced. A booking that didn’t work, a screen that was hanging, an order that didn’t go through.

We have turned that around in recent months. We now monitor telemetry for the Business Central environments we manage daily. Every evening, a report compares the past 24 hours to the previous week’s average. If something catches our eye, we will go to it. Often before the customer even realizes that something is going on.

The striking thing is that most of the things we find like this have never been received as complaints. Users get used to a slow screen or an error message that is “just part of it”. That’s where the profit lies.

What exactly is telemetry?

In the background, Business Central tracks everything happening within the system: which processes take a long time, where tables are waiting on one another (locking), which error messages users encounter, and which integrations fail. This data is always available, yet hardly anyone looks at it. We do. Not just as a one-off analysis, but daily using set checks and alerts that email us the moment something deviates from the norm.

Below are a few real-world examples from the recent period.

Example 1: everyone posting transfer orders at the same time

At a client with a large warehouse, we observed 61 database lock timeouts in a single day. Almost all of them (54) occurred in the same place: the registration of warehouse journal lines. The cause was simple. During the day, the warehouse journal was being used intensively by multiple people simultaneously to post transfer orders. These postings competed for the same records in the database, forcing users to wait for one another.

No one had submitted a support ticket regarding this, yet the entire operation felt the impact: other users attempting to post transactions at the same time also faced delays.

We recommended batching these postings and, wherever possible, scheduling them for outside peak hours. We discussed this approach with the warehouse’s key user. It wasn’t a technical fix but rather a workflow change that made the system faster for everyone.

Example 2: the inventory valuation process that takes increasingly longer

“Adjust Cost – Item Entries” is a standard batch process in Business Central used to update inventory valuation. At one client, we observed that this process was taking increasingly longer to run; while active, it locked tables that were also being accessed for daily operations, resulting in intermittent lock timeouts.

Upon analyzing the batch’s workload, we discovered that nearly 85% of the items being processed were service-related, such as travel charges, surcharges, and contract-based items, which have no cost to revalue. Despite this, the system was recalculating them on every run, with some entries dating back to 2023. Furthermore, old, uninvoiced receipts and returns were keeping the processing chain open.

The solution was surprisingly simple: we adjusted a single setting for the relevant items to exclude them from the cost adjustment process and cleaned up the legacy receipts. We established a baseline beforehand, identifying over 10,000 open entries so the impact could be clearly demonstrated. The client’s reaction spoke volumes: they were quite surprised that this issue had gone unnoticed for three years.

At another client, the situation was the opposite. Cost adjustment was set to “manual,” yet the data showed there was no backlog whatsoever. We were able to safely switch the setting to “automatic,” eliminating a daily manual task. At the same time, we identified dozens of purchase receipts that had never been invoiced, leaving orders and inventory entries open unnecessarily. After cleaning up approximately 2,700 old purchase orders, both the cost calculation process and the retrieval of lines for purchase invoices became noticeably faster.

Example 3: error messages that are never reported

On a Saturday morning, we noticed that one user was encountering an unusually high number of error messages over a few hours. The posting of a purchase invoice was blocked five times. When searching for a general ledger account, the message “No general ledger account in the filter” appeared ten times in a row. Furthermore, the bank reconciliation contained an entry with an account number that did not correspond to any known supplier.

Nothing was fundamentally broken. It was simply someone struggling with their bookkeeping on a Saturday. Instead of waiting for a support ticket to arrive on Monday, we took the initiative and sent a brief email: we noticed this are you running into any issues? Would you like us to take a look with you?

That is precisely the difference. The user doesn’t have to explain what went wrong, because we already know.

Example 4: the integration that reported “successful” while it actually failed

For one of our clients, an integration between their scheduling software and Business Central failed to process a specific scheduling update. Upon investigating the telemetry, we discovered that this had occurred 15 times over the past 30 days out of nearly 4,000 total updates. That’s 0.4%. A small figure, certainly, but a troublesome one, as the integration incorrectly reported the step as successful. No one noticed until a technician arrived at the client’s location at a time other than the originally scheduled one.

The client’s question was entirely reasonable: how can we monitor this during the evenings and on weekends? Our solution: a check that runs every hour, 24/7, to detect whether this specific error has occurred. If it does, an email is sent immediately, including the relevant order number. In the meantime, we are working on a structural, long-term fix.

What it yields

Proactive support is not about resolving more tickets; it is about reducing the burden on users. Here is what we have observed over the past few months:

• Issues are addressed while they are still small. Adjusting a setting or tweaking a workflow is far less costly than investigating a major disruption a month later.
• “Silent” errors are brought to light. Processes that report “success” while failing to actually perform their intended task often go unnoticed in standard error logs, but they show up clearly in telemetry.
• The nature of the conversation shifts. We no longer just provide answers to questions; we offer insights into the client’s own environment—identifying where bottlenecks occur, why they happen, and what the impact is.
• Greater confidence in the system. During a monthly review, a client noted that our proactive focus on stability and speed has significantly boosted their trust in Business Central. For us, that is the most important outcome.

Reactive or proactive?

Reactive support remains necessary. There will always be questions and issues that only a user can raise. However, if the only time your partner looks at your environment is when something goes wrong, you are missing out on a great deal.

This leads to a question for you: do you want reactive support for your Business Central environment, or proactive support? Would you prefer to wait until something goes wrong, or have someone keeping an eye on things and calling you before that happens?