--- title: "How we tested BOXL CRM before the London pilot | 3tf" description: "The virtual business, operational failures, fixes and saved checks behind BOXL before adaptation for a real London moving and storage company." url: https://3tf.agency/blog/boxl-crm-testing-before-london-pilot --- [All articles](https://3tf.agency/blog/) Moving and storage 9 min read # Before the London Pilot: How We Tested BOXL, Found the Failures and Strengthened the System. The virtual business, operational failures, fixes and saved checks behind BOXL before adaptation for a real London moving and storage company. Founder, 3tf · 12 November 2026 ![A BOXL storage unit with furniture under blankets, and the BOXL CRM storage map showing every unit by zone.](https://3tf.agency/img/blog/boxl-crm-testing-before-london-pilot-960.webp) The idea in brief We tested connected moving and storage workflows, corrected failures in billing, quoting and staff coordination, and added checks around the cases that failed before adapting BOXL for an operating London company. A moving and storage business depends on hundreds of small decisions being recorded correctly. An enquiry becomes a quote. A customer accepts it. A deposit is recorded. A crew receives a job. Goods arrive at the warehouse. A storage unit becomes occupied. Monthly invoices continue until the customer leaves. When those steps connect properly, the business can operate with a clear view of its customers, capacity and money. When they do not, the consequences can be expensive: missed invoices, conflicting bookings, forgotten jobs, incorrect balances or employees unable to complete routine work. Before adapting BOXL for an operating London company, we put the system through virtual business modelling, operational testing and repeated checks of its underlying rules. The process exposed bugs. We investigated them, changed the software and added checks around the cases that had failed. That work is an important part of the BOXL story. ## 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: | Virtual staff member | Role represented in the CRM | Operational perspective | | --- | --- | --- | | Dana Whitfield | Managing director / owner | Oversight of the business, settings, team and financial picture | | Sam Okafor | Operations manager | Coordination of enquiries, bookings and operational work | | Lucy Chen | Customer operator | Customer records, communication and enquiry follow-up | | Priya Shah | Warehouse keeper | Warehouse work, stored goods and handovers | | Tom Riley | Driver | Collections, deliveries and assigned transport work | 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. Enquiries and moving workflows in the demonstration CRM. Select the collage to view it full size. ## 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. Billing and operating analytics in the demonstration CRM. The figures are fictional. Select the collage to view it full size. ## 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](https://boxl24.com/) - [Try the demonstration CRM](https://boxl24.com/crm/) - [Watch the video lessons](https://boxl24.com/crm/guide/videos/) - [Read the staff guide](https://boxl24.com/crm/guide/) - [Download the guide: From Enquiry to Payment](https://boxl24.com/crm/guide/pdf/BOXL-CRM-1-enquiry-to-payment.pdf) - [Download the guide: Warehouse Operations](https://boxl24.com/crm/guide/pdf/BOXL-CRM-2-warehouse-operations.pdf) - [Explore the BOXL brand](https://boxl24.com/brand/) - [Contact 3tf](mailto:niki@3tf.agency) *By Nikita Lutsenko, Founder of 3tf* Share this article [[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2F3tf.agency%2Fblog%2Fboxl-crm-testing-before-london-pilot)](https://wa.me/?text=Before+the+London+Pilot%3A+How+We+Tested+BOXL%2C+Found+the+Failures+and+Strengthened+the+System+https%3A%2F%2F3tf.agency%2Fblog%2Fboxl-crm-testing-before-london-pilot) [WhatsApp](https://t.me/share/url?url=https%3A%2F%2F3tf.agency%2Fblog%2Fboxl-crm-testing-before-london-pilot&text=Before+the+London+Pilot%3A+How+We+Tested+BOXL%2C+Found+the+Failures+and+Strengthened+the+System) [Telegram](https://twitter.com/intent/tweet?url=https%3A%2F%2F3tf.agency%2Fblog%2Fboxl-crm-testing-before-london-pilot&text=Before+the+London+Pilot%3A+How+We+Tested+BOXL%2C+Found+the+Failures+and+Strengthened+the+System) X **Written by Nikita Lutsenko** I founded 3tf Digital Marketing Agency and Soltech Solutions, and I work from Dubai with clients across the UAE, the GCC and worldwide. Here I write about the decisions behind better websites, marketing and business technology. Have a project in mind? Let’s talk through your priorities. Follow 3tf [Instagram](https://www.instagram.com/3tf_digital) [Facebook](https://www.facebook.com/3tf.agency) [Threads](https://www.threads.com/@3tf_digital) [LinkedIn](https://www.linkedin.com/company/3tf-agency) [TikTok](https://www.tiktok.com/@3tf.agency) [YouTube](https://www.youtube.com/@3techflow) [Pinterest](https://www.pinterest.com/3tf_Digital_Agency_Dubai) [X](https://x.com/3TechFlow) [Google Business](https://www.google.com/maps/place/3TechFlow/@25.1576084,55.2924306,17z/data=!4m8!3m7!1s0x3e5f69f0c9bedf3f:0xb6dae99c588ed7c3!8m2!3d25.1576084!4d55.2924306!9m1!1b1!16s%2Fg%2F11zz0h6mdl?hl=en) In this article Your next move ## What should your business focus on next? Take our five-question growth quiz. Share your details at the end to receive your plan. The quiz needs JavaScript to build your plan. You can also share your business, priorities, budget and timing with us directly. ## Keep reading [All articles](https://3tf.agency/blog/) **Nikita Lutsenko** Founder, 3tf Product development 10 min read ## [We have built our moving and storage CRM. Now we are adapting it for London.](https://3tf.agency/blog/boxl-crm-moving-storage-london) Three years of sector experience, connected from the first enquiry to warehouse operations, recurring billing and daily analytics. Explore BOXL and what we can adapt for your business. **Nikita Lutsenko** Founder, 3tf Case study 10 min read ## [BOXL: a complete ecosystem for storage and moving.](https://3tf.agency/blog/boxl-storage-business-website-crm) Our website, CRM and brandbook foundation for storage and moving partners: local adaptation, demand research and lead generation through Google Ads and Meta. CRM and automation 4 min read ## [The form is only the start: connecting your website and CRM](https://3tf.agency/blog/website-crm-follow-up) What happens after someone clicks send? How to route each enquiry, give it an owner, follow it up and measure which leads become sales. --- 3tf (3TechFlow L.L.C-FZ) is a Dubai-based digital marketing agency. Contact: niki@3tf.agency, +971 50 783 7050. This is the Markdown version of https://3tf.agency/blog/boxl-crm-testing-before-london-pilot; every page is listed in https://3tf.agency/llms.txt.