System Breakdown // Product Ownership

The CRM that replaced a decade of spreadsheets.

Global armoured vehicle sales ran on Excel workbooks and an Access database — workable at small scale, blind at real scale. I owned the product design of its replacement: a custom CRM whose every schema decision encodes how long-cycle B2G selling actually works.

Product Scope July 2026 — live in production

Lead lifecycle states

Opportunity states

Source attribution classes

Units

Pipeline denomination

Core modules: Leads · Opportunities · Role dashboards · Coordination calendar. Role-based dashboards carry fiscal-year unit targets, activity and funnel views, and a follow-up tracker. Pipeline figures, client identities, and deal data are deliberately not shown here.

From workbook to operating system.

Excel + Access era

Custom CRM

Excel workbooks + Access, passed between users with version-name file management

Multi-user web CRM with role-based access, live for the sales team

One row = lead, opportunity, and notes at once

Separate lead and opportunity objects with distinct lifecycles and proposal states

Lead origin remembered, argued, or lost

Mandatory source attribution: self-prospected / company-provided / other

Follow-ups dependent on individual discipline

Dated follow-up tracker with reminders on the dashboard

Management reporting = manual consolidation before reviews

Live funnel, activity, and target-achievement views per role and date range

Tender deadlines tracked outside the sales tooling

Tender calendar in-system, including automated tender discovery

Six decisions that define the product.

None of these are technical flourishes. Each one encodes something true about how armoured vehicles are actually sold — which is what a custom CRM is for.

The pipeline is denominated in units, not just money

Dashboards track pipeline units alongside estimated value, and sales targets are set as units confirmed per fiscal year. A deal is N vehicles in a configuration; revenue is derived from that, not typed over it.

Why not the obvious alternative Generic CRMs model deals as a currency amount with a probability. In armoured vehicle sales the unit count and configuration are the deal — value follows from them. Modeling the domain's real primitive was the single biggest break from both the Excel era and off-the-shelf CRM defaults.

Leads and opportunities are separate objects with separate lifecycles

Leads move through their own status set (cold → hot → opportunity → rejected) before conversion; opportunities then carry their own temperature and a first-class proposal state — "not initiated" vs "proposal generated" is tracked data, not a comment.

Why not the obvious alternative In the spreadsheet era one row served as lead, opportunity, and proposal log at once — so nobody could say how many real opportunities existed or which ones had never received a proposal. Splitting the objects made the funnel measurable at each conversion point.

Lead source attribution is baked into the schema

Every lead is classified at entry: self-prospected, company-provided, or other. Dashboards split performance along exactly these lines, next to each BDM's fiscal-year unit target.

Why not the obvious alternative When attribution lives in people's memory, target reviews become arguments. Making source a mandatory field turned "who actually generated this" from a debate into a report — and made self-prospecting visible enough to be worth doing.

Follow-up is a system function, not a habit

A follow-up tracker with dated reminders sits on the dashboard; every lead and opportunity row carries an add-follow-up action. The failure mode being engineered against: first contact, then silence.

Why not the obvious alternative Excel cannot nag anyone. In long-cycle B2G sales where deals move over months, the system that remembers on the seller's behalf is the difference between a pipeline and a contact list.

Tender deadlines live in the same system as the pipeline

A coordination calendar carries corporate events, country-specific national days, and tender deadlines — both manually added and system-found tenders surfaced by automated discovery — exportable per date range.

Why not the obvious alternative Tender dates in one tool and pipeline in another means missed deadlines fall between systems. Putting automated tender discovery inside the CRM connects "an RFP exists" to "someone owns it" in one place. National-day tracking matters in this market: outreach timing around them is a real variable.

Owned as a product, delivered through a partner

I owned the product: lifecycle design, field schema, source attribution rules, dashboard and reporting logic, and role structure. A development partner built and maintains the application to that specification.

Why not the obvious alternative Pretending to have coded it would be the flattering version — and the fragile one. Product ownership is the honest claim and the transferable skill: knowing what the sales operation needs, specifying it precisely, and iterating it against real usage.

Disclosure

Described from the live production system as of July 2026. The application was developed by an external partner to an internally owned product specification; my role is product ownership — lifecycle design, schema, reporting logic, and iteration against real sales usage. All pipeline figures, client names, and deal details are excluded by design.

Want the deeper walkthrough?

I can walk through the lifecycle model, the attribution and target logic, and how the product evolved from the first spreadsheet audit to the current build.

Book a system walkthrough