Case Study · Family Poultry Distribution (RCD)

Three decades of records, one manager carrying the ledgers on trips, and a business that could not stop.

RCD is a medium-sized poultry distribution business in the Philippines that has been operating for more than three decades, and it is still growing. Its transaction volume is high, its operating day is complex, and until this engagement, its entire memory lived on paper. Studio JNSQ moved that memory to the cloud in two weeks, and the business found hundreds of thousands of pesos it had lost along the way.

2 weeks
Delivery Window
41%
Aged AR Collected
5–10 hrs
Weekly Time Recovered
RVF™
Framework Applied
Back to portfolio
Who they are

Thirty years of operation, still growing, still keeping the records by hand.

The client, referred to here by its initials RCD, is a medium-sized family-owned poultry distribution business in the Philippines that has been in operation for more than three decades. It is not slowing down. On any given day, multiple trucks run multiple trips, and the operational floor layers loading exchanges, culling, supplier settlements, and customer collections into the same working window. It is a capital-intensive business, and it moves quickly.

What made RCD unusual was not the volume; it was the medium. Everything above — every transaction, every customer account, every receivable balance, every reconciliation — lived on paper. Thirty years of physical ledgers, still hand-written, still the source of truth. The records were the business, and the records were the risk.

Client
Family-owned poultry distribution, referred to as RCD
Sector
Agriculture, poultry distribution, Philippines
Tenure
30+ years in operation, medium-sized, still growing
Operational Reality
High transaction volume, multi-truck days, supplier and customer exchanges layered into the same window
Engagement
RVF™ Advisory + Execution: Cloud-Native Operating System
Delivery Window
2 weeks (ahead of the owner's international trip)
The bind they were in

The records were fragile, the manager was the bottleneck, and the expenses were invisible.

The owner needed to travel, and travel is where the three failure modes of the paper system stacked on top of each other in the worst possible way. Normally, the manager would take the physical customer ledgers with him on trips, so that he could keep the collection notes moving by hand while he was away. That is not portability; that is the records holding the business hostage. And it made every one of the paper-era problems worse at exactly the moment they needed to be smaller.

First was the fragility. A damaged or misplaced book could take decades of accounts receivable, sales history, and customer context down with it, permanently. Second was the manager himself becoming a bottleneck — not because of anything he was doing wrong, but because reconciliation, allocation, and customer follow-up all lived in his handwriting and his memory. When he was travelling or attending to other work, the business waited on him. Third was expense drift. The business carried a growing tail of non-operating expenses, and they piled up quickly. The owner wanted to be able to look at a period, at a glance, and know: why is this month bigger, and were there unusual items I should have seen coming. None of that was answerable from the paper trail.

How we approached it

We did not migrate thirty years of records. We gave the business a clean starting line.

The instinctive move on a digital transformation this old would be to migrate the historical data first, spend months tracing missing entries, and stand up the system on the back of a full reconstruction. That approach would have failed here for two reasons. First, the delivery window was two weeks; there was no time to relitigate three decades of paper. Second, the historical records were themselves incomplete, and forcing them into a modern schema would have produced a system whose ledger nobody trusted from day one.

So we did something quieter, and more useful. Rather than migrating the past, we designed the system to accept opening balances: a clean, deliberate starting point that the business could set as-of a specific date, with the older paper records kept in their original form as reference. The one exception was accounts receivable, because AR is the one place where the past is still an active balance sheet item. So we spent a focused stretch of the engagement combing through the 2026 records from the start of the year, surfacing aged receivables that had been buried inside the manual ledgers, and adding them to the opening balances as the system went live. That single exercise turned into the largest cash-flow moment of the entire engagement.

Feature: the dashboard

Organized around the batch, because that is how the business already thinks.

The dashboard is not the first thing we built; it is the last, because it can only exist once the underlying operational units are right. And the operational unit for RCD is the batch — a shipment run, with its own suppliers, customers, sales lines, expense lines, and reconciliation. Every chart on the dashboard reads through that lens: net income per batch, sales composition by classification, expense breakdown for the period, and inventory reconciliation across batches so that the manager can see, at a glance, whether the birds that came in have accounted for the birds that went out.

[CLIENT ANONYMIZED]
Batch Records · Cloud CRM
👤 JML | + Save Snapshot
Net Income per Batch
Profit Loss Last 8 batches
Sales by Classification
Class A 42%
Class B 28%
Culled 20%
Loading 10%
Expense Breakdown
Operating Fuel & ops Non-op unusual
Inventory Reconciliation Across Batches
Batch 24-11 · in 28,500 · sold 28,320 · culled 180Balanced
Batch 24-12 · in 26,200 · sold 25,960 · culled 210Δ 30
Batch 24-13 · in 31,400 · sold 31,180 · culled 220Balanced
Batch 24-14 · in 29,800 · sold 29,610 · culled 190Balanced
RCD Dashboard. Four analytical panels, all organized around the batch. Inventory reconciliation is the visible discipline: every bird that came in has to account for a bird that went out (or a loss recorded). Dummy data.
Feature: the operational unit

The batch stayed the same; only the medium changed.

In RCD's mental model, everything happens inside a batch — a shipment run, with its own suppliers, customers, sales lines, expense lines, and reconciliation. That vocabulary was built over thirty years, and it is exactly right for how poultry distribution actually works. So the system was designed around the batch as the primary object, rather than forcing the business into a generic invoicing model that would have felt foreign from day one.

[CLIENT ANONYMIZED]
Batch Records · Cloud CRM
👤 JML | + Save Snapshot
All Batches (illustrative rows)
BatchDate InHead InSoldCulledNet ₱Status
Batch 26-01Jan 0828,50028,320180₱2,845,600Closed
Batch 26-02Feb 0426,20025,960210₱2,468,200Reconcile
Batch 26-03Feb 2831,40031,180220₱3,124,800Closed
Batch 26-04Mar 2629,80029,610190₱2,780,400Closed
Batch 26-05Apr 2232,70032,450250₱3,020,500Live
Batch 26-06May 1730,9009,40060₱856,200Selling
Batches. The core operational unit in one view. Batches move through three states: Live (in progress), Reconcile (needs a manager check), and Closed. Sortable, filterable, exportable. Dummy data.
Feature: the safety net

Every destructive action creates a snapshot, automatically.

When we asked the manager what he was most anxious about with digital tools, his answer was not about learning curves; it was about accidental deletion. Thirty years of paper had taught him that mistakes are permanent, and he had never fully believed that a computer could be more forgiving than a spreadsheet with a stray keystroke.

[CLIENT ANONYMIZED]
Batch Records · Cloud CRM
👤 JML
Version History · Snapshots are created automatically before any destructive action
Jul 07, 09:14 · before delete Batch 26-01
auto-snapshot
Jul 06, 15:42 · end of Batch 26-05 sales day
manual snapshot · JML
Jul 05, 08:07 · before bulk-delete non-op
auto-snapshot
Jul 03, 18:22 · end of week close
manual snapshot · JML
Jul 01, 07:00 · before reset expenses
auto-snapshot
⚠ Danger Zone
These actions are guarded by automatic snapshots — but still confirm before pressing.
Version History + Danger Zone. Every destructive action creates a snapshot before it runs (auto). Manual snapshots are one click. Everything can be downloaded as JSON and kept outside the system.

The reset button lives in a section literally labelled Danger Zone, and even that is guarded by the automatic snapshot behaviour. It is a small kind of grace to build into a tool, and it is the reason the manager stopped hesitating on the third day.

Feature: the on-ramp

A fifteen-line modal that made a thirty-year migration unnecessary.

The Opening AR modal is a small piece of UI that carries the entire delivery strategy behind it. Because we designed the system to accept balances forwarded from an older ledger, we did not have to prove the historical data was complete; we only had to prove that today's balance was correct. That single move turned a six-month migration project into a two-week implementation.

[CLIENT ANONYMIZED]
Batch Records · Cloud CRM
👤 JML

Record Opening AR Balance

Use this for receivables that pre-date the transactions in this system — e.g. balance forwarded from an older ledger.

Buyer β · [Region redacted]
2026-06-15
1,285,600.00
Ledger book #14 · page 22
Illustrative — balance forwarded from a physical ledger, verified against the 2026 record-combing exercise.
Opening AR Balance modal. Every recovered aged balance came in through this modal. Reference field allowed the ledger book and page to be recorded, so paper history stayed traceable while the digital record moved forward. Dummy data.
Feature: answering the owner's real question

Non-operating expenses live in their own tab, so nothing hides inside a total.

Non-operating expenses had a way of piling up inside a paper system, because they did not tie cleanly to any batch and nobody wanted to spend the mental effort of categorizing them mid-shift. Over time, that tail became the specific place where the owner was losing visibility. So we gave non-op expenses their own tab, kept them fully separated from operating cost, and surfaced the whole expense mix on the dashboard as two views at once.

[CLIENT ANONYMIZED]
Batch Records · Cloud CRM
👤 JML
Non-Operating Expenses · July 2026
Regular non-op
Business permits renewal · Jul 03₱185,000
Office rent · Jul 01₱245,000
Association dues · Jul 04₱42,000
Company training program · Jul 02₱168,000
⚠ Unusual · auto-flagged
Facility maintenance contract · Jul 05₱485,000
Professional consultation · Jul 02₱225,000
Flagged when the line item exceeds the 90-day category average by 2× or more.
Non-Op Expenses. Separated from operating cost so they cannot hide inside a total. Unusual items are auto-flagged when they exceed the 90-day category average by 2× or more. Dummy data.

The owner can now ask the same question she always asks — what changed this month — and get the answer before she finishes the sentence.

Feature: aged receivables that stop hiding

Every customer with an outstanding balance now has a card, and the aged ones surface first.

Before the engagement, the owner had accepted that some receivables would eventually be written off as bad debt, not because the customers were unreachable, but because tracking each account's balance and history across a stack of hand-written ledgers was too expensive to do well. The work of collection was possible; the seeing was what was broken.

[CLIENT ANONYMIZED]
Batch Records · Cloud CRM
👤 JML
Total Outstanding
Illustrative · 12 buyers, 5 aged
₱8,528,600
Buyer β · [Region redacted]
Opening balance · Jun 15 · ledger #14
Aged 22d
₱1,285,600
Buyer μ · [Region redacted]
Batch 26-05 · 3 unpaid deliveries
Aged 8d
₱1,845,200
Buyer τ · [Region redacted]
Recovered from 2026 record-combing
Aged 45d
₱968,400
Buyer γ · [Region redacted]
Batch 26-04 · part-paid Jun 28
Current
₱747,000
Buyer π · [Region redacted]
Recovered from 2026 record-combing
Aged 60d
₱1,485,000
Accounts Receivable cards. Aged balances surface first, sorted by days outstanding. The two “Recovered” entries were surfaced during the 2026 record-combing exercise and added via the Opening AR modal. Dummy data.

The record-combing exercise put hundreds of thousands of pesos back into visible AR that had been buried in the paper records, and 41% of those aged balances have been collected since implementation. Average collection time improved by two to three days, quietly, without any change to the collection process. Only the visibility changed.

In the manager's words

What JML said, unedited.

This system not only allowed me to travel and enjoy my off times, but also really streamline the sales and collections process to make sure the business is not losing money anywhere.

JML · Sales and Finance Manager, RCD
What changed on the ground

Time back on the calendar, cash back in the ledger, and a bottleneck that stopped bottlenecking.

The manager travels now without the ledgers. The books stay behind, and the business does not stop when he is out of the office, because the system holds the operational picture and multiple people can move against it at once. That single change — the elimination of the single point of failure — had knock-on effects that reached every corner of the operating day.

Approximately five to ten hours per week came back to the manager's calendar, and in complex-transaction periods (multi-truck days, layered supplier and customer exchanges), the savings on audit alone ran two to five hours per period. The double-entry and lost-cash-flow risks that came with manual re-writes across ledgers are automated away. Cash holdings, the single most sensitive metric for a capital-intensive distribution business, are now visible at any moment, in any location.

Time Recovered
5 to 10 hours per week saved on reconciliation and data cascades. 2 to 5 hours saved per audit period on complex-transaction days.
Aged AR Collected
41% of flagged aged receivables collected since implementation. The 2026 record-combing exercise recovered hundreds of thousands of pesos in previously buried balances.
Collection Cycle
Average collection time improved by 2 to 3 days. Aged balances now surface in-system, instead of appearing during an owner review.
Data Integrity
Double-entry and lost-cash-flow risks are automated away. Cash holdings are visible at any moment, from any device.
Where the business is going next

The recovered attention is now studying two new markets.

RCD handles high transaction volume, and the system has been running long enough to surface real patterns rather than one-month noise. That is where the compounding effect of the Resource Value Formula™ starts to show up in the shape of the business itself. When you recover a manager's calendar, an owner's visibility, and a receivables position all at once, the question stops being how do we survive the next week and starts being where do we grow to next.

RCD is now studying market expansion into Visayas and Mindanao. Both regions carry logistics complexity that the paper era would have made unreadable in time to act on; both regions look answerable now, because the operating picture is finally visible day-by-day rather than reconstructed at month-end. That is the whole thesis of the RVF™. Recover the resource, and the business grows into a shape it could not previously see.

About this case study. Prepared by Studio JNSQ based on a client engagement, published with the client's consent under anonymized attribution. The client is referred to by its initials (RCD) and its industry (poultry distribution, Philippines). System replicas shown throughout are Studio JNSQ-built HTML mocks that mirror the actual design language of the deployed system, populated with dummy data. Results are measured against the scope that was agreed. No outcomes outside the brief are claimed.
Back to portfolio
Want to know where your resources are leaking?

Take the Resource Value Formula™.

The same framework that anchored this engagement is available as a free diagnostic. Twenty questions across four aspects, five to seven minutes.