Most businesses have at least one person who knows far more than their job description suggests.

They know which customer gets a special price, which supplier usually has a certain product, where the latest spreadsheet is stored, which manager needs to approve a large discount, how the ERP has to be updated after an order is confirmed, and what to do when the normal process does not quite fit.

As long as that person is available, the business appears to run smoothly.

The weakness only becomes visible when they are absent.

At JH Systems, we see this as more than a staffing problem. It is often a systems problem. If an important business process depends on information that exists only inside one person's memory, private spreadsheet, inbox or WhatsApp history, then the company itself does not fully own that process.

That is the idea behind what we call the 24-Hour Business Resilience Test.

The question is simple. If one key employee was unavailable tomorrow, could another person complete the same work without calling them for help?

For many businesses, the answer is uncomfortable.

The solution is not to make employees less important. It is to make the business less dependent on undocumented knowledge and manual coordination.

The following examples show how that problem appears in different industries, and where different JH Systems services can actually come into play.

Case Example One: The Salesperson Who Quietly Runs the Quotation Process

Consider a trading and distribution company that sells hundreds of products to corporate customers.

One senior salesperson has been with the company for years. When an enquiry arrives, he immediately recognises many of the customer names. He knows which products they normally buy, which alternatives can be offered when something is unavailable, and which customers receive special pricing.

The company technically has an ERP and customer records, but much of the useful commercial knowledge still sits outside those systems.

The latest supplier prices may be in an Excel file. Previous discussions may be buried in email or WhatsApp. Some customer discounts exist because “we have always given them that rate,” even though the rule has never been properly recorded.

A quotation arrives on Monday morning asking for twenty units of one item and ten units of another.

Normally, the salesperson would read the request, open his pricing sheet, check the ERP for stock, look at an old quotation, calculate a price, ask the sales manager for approval through WhatsApp, prepare the quotation and send it.

Now imagine he is on leave.

Another salesperson opens the enquiry and immediately encounters questions. Which price list is current? Is the customer still entitled to the old discount? Can Product B be substituted with Product C? Does the manager need to approve the margin? Which supplier should be contacted if current stock is insufficient?

Nothing is technically broken.

The business has simply discovered that part of its commercial process exists inside one person's head.

This is where several JH Systems services can work together.

The first layer is usually ERP and CRM structuring. Pricing rules, customer terms, product records, stock availability and previous sales information should be maintained centrally wherever possible. If the company uses Odoo or another ERP, the goal is to configure and customise the system so that the commercial information employees actually rely on is available there.

The CRM can then hold proper customer history, opportunities, quotation activity and follow-up information rather than leaving those records scattered across individual inboxes.

The second layer is workflow automation. If quotations above a certain discount or below a certain margin require approval, that rule should not depend on the salesperson remembering who to message. A structured approval workflow can route the request to the correct manager, record the decision and continue the process afterward.

The third layer is PLOC AI.

Customer enquiries rarely arrive in a perfectly structured format. One customer may send a clean spreadsheet, another may attach a PDF, and another may simply write a paragraph explaining what they need.

PLOC AI can help interpret those incoming requests, extract relevant information, identify the customer, retrieve information from connected systems and prepare the workflow for the next step.

The salesperson still remains responsible for the commercial relationship and important judgement. What disappears is the need for one person to manually hold the whole process together.

The result is not that the experienced salesperson becomes less valuable. The opposite happens. Their experience can be used for negotiation, customer relationships and complex decisions instead of being consumed by repetitive administrative work.

Case Example Two: The Maintenance Company Where One Coordinator Knows Every Customer

Now consider a service and maintenance business.

Customers contact the company when equipment fails, requires servicing or reaches its scheduled maintenance date.

One service coordinator handles most of these requests.

When a customer messages on WhatsApp, she knows the account immediately. She remembers whether the machine is under contract, which technician normally handles that site, where the customer's previous service report is stored and which spare parts may be required.

This knowledge makes her extremely effective.

It also creates risk.

If she is absent, a new request may require another employee to search through several places just to understand the situation.

The customer's contract could be in a shared folder. Equipment details may be inside a spreadsheet. Previous technician notes may have been sent through WhatsApp. Invoices may exist in accounting software. The service history may not be available in one place at all.

What normally takes five minutes may suddenly take half an hour.

JH Systems would approach this differently from the trading-company example because the problem is not mainly sales. It is service workflow coordination.

The first step could involve creating or customising a service management workflow inside the ERP or a custom business application.

Customer records can contain equipment information, contract status, previous jobs and service history. A new request can become a structured service ticket rather than simply remaining as a message.

Technician assignment can also become part of the system.

Instead of one coordinator remembering that Technician A normally handles a certain type of machine, the workflow can consider service category, customer location, technician availability or other rules that matter to the company.

If the company's existing software does not support the exact workflow, JH Systems can develop a custom module or dedicated application around the requirement.

This is where custom development matters. Not every business process fits perfectly into a standard ERP screen, and forcing employees to work around the software simply creates another version of the original problem.

PLOC AI can also play a role here when the incoming request is unstructured.

A customer might write, “The machine in our workshop is showing the same error it had last month. Can someone come tomorrow morning?”

That message contains information a normal form may not capture neatly.

PLOC AI can help interpret the request, identify the customer, retrieve the relevant equipment or service history and prepare the request for the service team.

Once the technician completes the work, the system can help maintain the job record, service report and next stage of the workflow.

The employee who used to remember everything remains part of the operation, but the company no longer depends entirely on her memory.

Case Example Three: The Restaurant Manager Who Knows How Everything Connects

The same problem appears in hospitality, although the systems look very different.

Imagine a restaurant where one manager knows everything.

They know how the POS is configured, which products have special modifiers, which supplier usually provides a certain ingredient, where reservations are recorded, how delivery orders are handled, which employee is working which shift and what the normal stock levels should look like.

The restaurant has software, but its operation still depends heavily on that manager.

When they are away, small problems begin appearing.

Reservations may not be recorded consistently. Staff may not know whether an order should be treated as dine-in, takeaway or delivery. Purchasing decisions may depend on someone checking stock manually. Management reporting may involve exporting data and combining it somewhere else.

For this type of business, JH Systems would not try to solve the problem using the same generic ERP workflow used for a trading company.

This is where Clyro comes into play.

Clyro is designed around restaurant operations, so the POS, kitchen flow, reservations, customers, inventory, purchasing, delivery, cashbook, invoices and reporting can sit within the same wider operating environment.

The goal is to reduce the amount of restaurant knowledge that exists only in one manager's head.

If orders move from the POS into the kitchen properly, employees do not need someone to explain the process manually.

If reservations are maintained in the system, staff can see them without asking the manager.

If inventory and purchasing are connected to the restaurant operation, the business has more visibility into what is being sold and what may need replenishment.

If customer information and repeat activity are visible, the business is less dependent on someone personally recognising every regular customer.

PLOC AI can then be used around the edges of that operation where interpretation and communication are involved.

For example, incoming reservation requests or management summaries can potentially be handled through intelligent workflows while Clyro remains the operational core.

The key point is that the restaurant manager is still valuable.

Their expertise should be used for service quality, staff management and decision-making rather than simply remembering how every piece of software fits together.

Sometimes the Problem Is Not Missing Software

One of the most important things we look for during a dependency assessment is whether the company actually needs new software at all.

Sometimes it does not.

A business may already have a powerful ERP, but employees use spreadsheets because the ERP was never configured properly.

A CRM may already exist, but the team does not use it because the sales process inside the system does not match how they actually work.

The company may already store customer data centrally, but there is no integration between that system and another application employees use every day.

In these cases, the answer may simply be configuration, customisation or integration.

JH Systems can examine the existing environment before recommending another product.

If Odoo already contains the required functionality, we can configure or customise it.

If two applications need to communicate, we can build the integration.

If there is a gap that standard software cannot solve, custom development may be appropriate.

If the problem involves interpreting emails, documents or natural-language requests, PLOC AI can become the intelligence layer connecting those systems.

The right answer depends on the process.

The 24-Hour Test Makes the Risk Visible

The value of the 24-Hour Business Resilience Test is that it turns something vague into something observable.

Management often knows that certain employees are important.

That is normal.

What management may not know is exactly how much of the company's process depends on information that has never been properly captured.

We can take one process and simulate what would happen if the key person were unavailable.

We look at how many steps can continue without them, how many decisions rely on their memory, how many documents or spreadsheets only they understand, how many approvals happen informally and how many systems another employee must search before the process can continue.

The result should not simply be a report saying that the company has risk.

It should identify where the dependency exists and what can actually be done about it.

What JH Systems Might Recommend After the Test

The solution can be very different from one company to another.

A trading company may need ERP and CRM restructuring combined with a proper quotation approval workflow.

A service business may need a custom service-management process with customer, equipment and technician records.

A restaurant may benefit from moving fragmented operations into Clyro.

Another company may already have good systems but need integrations between them.

PLOC AI can be introduced when the process requires intelligent interpretation, such as reading customer enquiries, extracting information from documents or coordinating several systems based on context.

The important thing is that none of these technologies should be recommended simply because they exist.

They should solve a specific dependency that was discovered in the workflow.

That is how the project becomes tangible.

The Goal Is to Move Knowledge Into the Business

Experienced employees should know things that software cannot know.

They should understand customers, recognise unusual situations, negotiate, make judgement calls and use the experience they have built over years.

What should not happen is for basic business continuity to depend entirely on their memory.

A company should know its own pricing rules.

It should know its customer terms.

It should know where its records are.

It should know how approvals work.

It should know what happens after a customer request arrives.

When those things exist only inside one person's head, the business has not fully captured its own operating knowledge.

That is the real purpose of this exercise.

We are not trying to make employees replaceable.

We are trying to make the business resilient.

At JH Systems, that can involve ERP and CRM implementation, Odoo customisation, Clyro, PLOC AI, integrations, custom modules or entirely custom applications depending on what the process requires.

The technology comes after the problem is understood.

The first question is much simpler.

If one important employee took tomorrow off, what would stop?

That is where we start.