Petriko CRM - Unified Operational Intelligence for Xero & Ezidebit Businesses

The tools themselves aren't the problem. Xero is excellent at what it does. Ezidebit handles direct debit reliably. The problem is the gap between them - and between both of them and the operational domain where your actual business runs.

Xero holds financial truth: invoices, ledger entries, tax records, financial reporting. Ezidebit holds payment truth: direct debit agreements, collection schedules, payment history, failure states. Your operational domain - the customers, the assets under management, the contracts that bind them, the service events that flow from them - holds operational truth. None of these systems are inherently aware of the others. Decisions happen in the gaps between them.

When a contract changes, Xero doesn't automatically know. When a payment fails in Ezidebit, the team managing the operational side finds out by accident or not at all until it compounds. When a vehicle changes hands, the financial trail and the collection schedule don't update themselves. This is not a failure of any individual tool - it's a structural problem that requires a layer that sits across all three domains and keeps them in sync.

That layer is what Petriko is built to be.

One Platform, Every Domain

Petriko organises operational data into a unified structure. Every module is connected to every other - events in one domain propagate through the rest rather than staying isolated.

Dashboard. The first thing a manager sees is not a module-specific view but a cross-domain operational snapshot: how many active subscriptions, what the collection state looks like from Ezidebit, what's outstanding in Xero, how many vehicles are approaching compliance due dates, what the workshop load looks like. The dashboard is not a summary of one system - it's a view across all of them.

Customers. A customer record in Petriko is not a name and a phone number. It's a unified profile: contact details, linked contracts and their current states, vehicles in current or past subscription, financial state pulled from the Xero integration, payment history from Ezidebit, notes and documents attached to the record, and a full activity timeline. When a customer calls, the person picking up has the complete picture - financial, operational, and historical - in one view.

Fleet. Every vehicle is a first-class operational entity. Its record carries the full lifecycle: current subscriber if active, compliance due dates (registration, insurance, inspection), complete service history, and the chain of subscriptions that have been attached to it over time. Fleet management is not a standalone function - it's connected to the subscription domain, the workshop domain, and the compliance domain simultaneously.

Subscriptions. The subscription is the contract at the centre of the business model. It binds a customer to a vehicle with a complete audit trail. Lifecycle events - activation, renewal, suspension, close - propagate outward: a renewal triggers invoice generation in Xero, updates the Ezidebit collection schedule, and creates an audit record in the operational domain. Odometer readings logged against a subscription feed into service interval tracking and inspection workflows.

Workshop. Service events are domain events, not isolated job records. When a job is completed, the vehicle's service history updates. When an inspection is logged, the subscription's compliance state reflects it. When a service interval is crossed, the system knows - not after the fact, but at the point the threshold is reached.

Payments. Every Ezidebit collection event surfaces in a unified payment view linked to the subscription and customer it belongs to. Arrears are visible in real time. The payment domain is not a separate reporting module - it's part of the operational picture.

Fleet Is the First Domain, Not the Only One

The current production vertical is fleet subscription management - the specific operational model of a recurring-revenue vehicle subscription business running on Xero and Ezidebit. That's where Petriko is in production today.

But the architecture is general. Any recurring-revenue business that manages contracts, assets, and collections across Xero and Ezidebit faces the same structural problem: operational truth, financial truth, and payment truth living in disconnected systems. The subscription model, the event propagation architecture, and the integration layer work for any operator in that position.

Multi-entity operations are a first-class concern from the start, not an afterthought. Two Xero organisations, two Ezidebit accounts, entity-scoped data throughout - configured at deployment, not bolted on later.

The Gap Is the Problem

Operational intelligence isn't about replacing the tools your business runs on. Xero is the right tool for accounting. Ezidebit is the right tool for direct debit collections. Replacing either would be the wrong answer.

The answer is a platform that sits across all three domains - operational, financial, and payment - and makes them aware of each other. When something changes in the business, the financial and payment systems reflect it. When something changes in the financial or payment systems, the operational domain knows. The gap closes.

That's what Petriko is built to do.