Before the London Pilot: How We Tested BOXL, Found the Failures and Strengthened the System.

We built a virtual company with people, customers and an operating history.

The original demonstration dataset contained 200 fictional customer journeys. We then expanded the model with a retrospective trading history beginning on 1 January.

This was a virtual business timeline. Dates in the model represented simulated operations; they were not a claim that the company had traded for that length of time.

The history included enquiries that converted, enquiries that were lost, short and longer storage stays, monthly invoices, different payment methods, late payments and customers who stopped responding.

That variety mattered. A useful CRM must explain what is happening when a customer does something unexpected, as well as when everything goes to plan.

The virtual company also included five named staff profiles, representing the main responsibilities inside a moving and storage operation:

These profiles made the organisation visible inside the product. They also helped us examine a fundamental question: does each role have the information and permissions needed to complete its part of the process?

The automated tests exercised the system’s actions and permissions separately. The virtual staff profiles, generated business history and test executions each served a different purpose.

We made time part of the test.

Many operational failures remain invisible during a short demonstration.

A monthly invoice cannot become overdue if the calendar never advances. A contract cannot reach its end. A missed collection cannot become yesterday’s unfinished job.

Our testing therefore included an accelerated operational exercise covering 75 virtual days.

The CRM has an internal business date. Advancing that date runs its daily processing, allowing us to inspect what happens when billing dates, payment deadlines and operational dates pass.

We could examine questions such as:

• Does an occupied unit continue generating invoices after the initial contract term ends?
• Does a failed simulated payment produce the expected follow-up?
• Does an unfinished move become visible to the team after its scheduled date?
• Does running the same daily process again create duplicate records?
• Does renewing a contract accidentally charge the customer twice?

This was essential because a system can look correct on its first day and still behave incorrectly several billing cycles later.

The tests exposed failures that a polished demonstration could easily hide.

One of the clearest examples involved storage billing.

A customer’s initial contract term ended, but their goods were still occupying the unit. The system stopped generating further invoices.

For a storage operator, that is a serious gap: the warehouse remains occupied while the billing process loses track of the ongoing service.

We changed the logic so that monthly billing continues while the customer remains in storage. The team receives a single task to arrange renewal or move-out.

The regression check verifies the subsequent monthly invoices, confirms that the task is not repeatedly duplicated and checks that renewing the contract does not bill the same period again.

Another failure appeared when creating the first moving quote in an empty workspace.

The quote received an invalid reference: Q-NaN.

A populated demo can conceal this kind of problem because its counters and existing records are already present. A new customer implementation starts from a different position.

We corrected the initial numbering so that the first quote receives Q-1001, followed by the next valid reference. We also added repair logic for records saved with the earlier invalid reference.

The check now covers both a clean start and recovery of affected saved data.

Some failures were about coordination between people.

Expense approval exposed a problem in how the system distinguished employees.

One manager could not approve an expense submitted by another manager. The logic needed to distinguish the individual submitting the expense from the individual reviewing it.

We changed the approval rule and recorded both identities.

The corresponding test checks two outcomes: an employee cannot approve their own expense, while another authorised manager can approve it.

That distinction is small in code and substantial in daily operations.

Enquiry ownership also needed attention. In the staff CRM, creating a customer or enquiry did not reliably assign responsibility to the person who created it.

We corrected that behaviour and added a check that both records retain the creator as their responsible employee.

A team needs to know who owns the next step. Otherwise, an enquiry can exist in the database and still be neglected.

Other failures appeared at the handover between moving and storage.

A booked move could pass its scheduled date without starting and remain silent.

The record existed, but the system did not create the operational task needed to bring the missed job to someone’s attention.

We added that task and checked that advancing the calendar again does not create repeated copies for the same missed date.

We also checked the dependency between a move and its associated storage booking. Where the workflow requires the move to be completed first, the system must prevent staff from recording the storage move-in prematurely.

These checks protect the sequence of events. A status change should reflect work that has actually reached the required stage.

A separate logic audit found another boundary problem: a moving enquiry could enter a storage pricing and reservation route.

We corrected the distinction between those workflows.

The audit also exposed a broken reopening process. Resending an expired quote could leave the associated enquiry marked as lost. We changed the behaviour so the enquiry and quote remain consistent.

Financial reporting needed consistent records beneath it.

Payment methods were being recorded using different free-text descriptions.

That creates a reporting problem: two payments made through the same method can end up in different categories.

We standardised the stored methods as Card, Bank transfer and Cash, while preserving additional detail in a note.

The checks verify that older descriptions are normalised and that the payment record retains the useful detail.

We also tested connected moving calculations: the accepted quote, deposit, completed job, additional time or extras and final balance must agree.

The payment outcomes in these tests were simulated. They allowed us to test billing and follow-up behaviour without presenting test transactions as live customer revenue.

Fixing a bug was only part of the work.

We added regression checks around the failures so that later changes could be checked against them.

The saved results include 27 passing checks of connected business processes. They cover relationships between enquiries, quotes, deposits, invoices, jobs, storage bookings, payments and follow-up tasks.

Examples include preventing overlapping crew bookings, rejecting repeated acceptance of the same quote, checking overdue-payment follow-up and verifying that repeated daily processing does not duplicate the expected financial actions.

A separate saved logic audit contains 2,500 iterations. It recorded 1,050 accepted actions and 1,118 rejected actions; other iterations did not produce an action to execute.

Its recorded list of broken consistency rules is empty.

Those figures describe specific checks and their saved outcomes. They give us evidence that the tested rules held under those conditions.

They also give us something practical to build on: when a workflow changes, we can check whether previously corrected behaviour has broken again.

Only after the virtual testing stage did we move to adaptation with a real London business.

The next stage brought a different kind of evidence.

An operating London company supplied real business data, allowing us to adapt the system around an actual organisation rather than relying entirely on fictional records.

That transition matters.

Virtual testing helps expose logic problems in a controlled setting. Working with a real company brings its warehouse structure, terminology, pricing, staff responsibilities and operational exceptions into the implementation.

The sequence was deliberate: build the virtual environment, investigate failures, improve the system, and then apply that foundation to a real operating business.

BOXL remains at the pilot stage. The core moving and storage functionality has been built, and adaptation continues around the requirements of the business using it.

For investors and prospective partners, the development process is part of the product.

This work was demanding because every improvement had consequences elsewhere.

Changing a quote can affect a deposit. Changing a booking can affect crew availability. Changing a storage contract can affect invoices, occupancy, reminders and reporting.

We had to examine those relationships, reproduce failures and check the consequences of each correction.

The result is more than a set of screens. It is a connected operating system whose business rules have been exercised, challenged and improved.

Our wider approach brings together the website, CRM and analytics, with marketing and automation adapted around the business. Google and Meta advertising, SEO, content distribution and agent-assisted workflows form additional parts of that work, with their scope agreed separately.

For a moving or storage operator, the objective is straightforward: attract enquiries, manage them properly, coordinate the work and understand the outcome.

We are inviting moving and storage companies, implementation partners and prospective investors worldwide to explore BOXL and discuss the next stage.

You can inspect the demonstration, read the documentation and watch the lessons before arranging a conversation.

• Explore the BOXL website
• Try the demonstration CRM
• Watch the video lessons
• Read the staff guide
• Download the guide: From Enquiry to Payment
• Download the guide: Warehouse Operations
• Explore the BOXL brand
• Contact 3tf

By Nikita Lutsenko, Founder of 3tf