Print-on-demand press service: 12 modules, 20+ reports, one billable record

The situation

A distributor of HP Indigo digital presses — the largest such distributor worldwide — runs a service business on top of its equipment business. Presses are installed at customer sites and then live for years: they break, they need parts, they consume consumables in volume, they get training, and they are billed by print volume. The distributor’s own engineers service them, and the problems those engineers cannot solve escalate to HP.

That produces a company with two centres of gravity. Operations think in tickets: a CALL comes in, someone is dispatched, the press is fixed. Commercial think in money: a fee notice becomes an invoice, the invoice gets paid (or does not), and at the end of the month someone has to work out which service was never billed. The two sides had their own records, and the gap between them is where a service business leaks revenue.

The call we made

We built the commercial chain first, and made operations feed it. Most field-service systems start with the queue, because the queue is what the desk feels. That produces a system that is good at closing tickets and poor at getting paid. Here the expensive failures are not lost tickets — they are a repair performed and never invoiced, parts consumed and never charged, an invoice nobody can trace back to the CALL that justified it.

So the spine of the build is the money: fee notice (initialise, prepare, approve with the commercial manager, dispatch to the customer), invoice application, issue, send and return, then booking and line-by-line reconciliation. Every operational module was then designed to produce the quantities those documents consume — the labour hours, the parts issued, the impressions printed, the escalation it took. A CALL is not finished when the engineer says so; it is finished when it has become a priced, reconcilable record.

The machine is the master record, not the customer. Before any service exists, the press must exist: device number, model, customer, site, contract, goods detail by batch and serial number, authorisation code, first payment schedule, site-confirmation CALL, and finally a start-up with a named responsible engineer. We insisted on this ordering because it removes a whole class of failure: a press cannot be serviced off the books, cannot be billed against the wrong contract, and cannot have its installation facts reconstructed later from memory. It also means installation data becomes the billing basis instead of a document filed somewhere.

Reports are the system’s job, not a person’s. The commercial review runs weekly, and there are more than twenty reports across CALL, engineers, machines, parts, consumables, equipment payments, receivables, warehouse and commercial lines. If those have to be assembled by hand each week, they arrive late, they disagree with each other, and eventually they stop being produced. So the reporting layer runs in place, on the operational tables, on the same weekly rhythm as the business.

The dual-channel service model is a state machine, not an email. Our own engineers take the CALL first; if it cannot be solved by rule, it escalates — to a senior engineer, then to HP. Escalation is a recorded state with its own path and its own timing, because “we escalated it to HP” with no timestamp is how a press sits dead for a fortnight while two organisations assume the other is working on it.

What we built

Twelve business modules, multi-role, from installation to cash:

• Installation management — the full record chain from contract to start-up, with each step owning its paperwork and its responsible person.
• CALL management — intake with customer, product line, fault code and environment detail; dispatch by territory, skill and load; the engineer’s on-site record with attachments, hours and impression count; callback and closure; escalation and HP referral.
• Parts — inventory and ledger, requests raised against a CALL with approval, RMA and return handling, and consumption tied back to the job.
• Consumables — issue, return, write-off and reconciliation, since consumables are both inventory and revenue.
• Training — requests, plans and records for customer operators.
• Fee notices — the document that turns service into a receivable, with in-warranty and out-of-warranty classification and print volume as a billing input.
• Invoicing — application, issue, despatch, and return handling.
• Reconciliation — booking against fee notices and invoices, line by line, with adjustment history.
• Reporting — 20+ reports covering the operational and commercial lines above.
• Master data and permissions — models, consumable types, service territories, engineer skills and role-based access by department.

Result

The service division runs install-to-cash in one system. Every press is on the books before it is serviced, every CALL carries the facts a fee notice needs, and reconciliation can be worked customer by customer rather than reconstructed at close. Service cost is calculable because parts and hours are attached to the job that consumed them; the fee notice closes to cash instead of stopping at “sent”; invoices match fee lines individually rather than by total.

The reports are produced weekly without anyone assembling them, which is the part customers underestimate: a 20-report set that is generated is a management instrument, and the same set that has to be built by hand is a monthly rumour.

Why we lead with this case

Because it is the case where the domain decision — which record the business actually revolves around — mattered more than any technology choice. We did not build the obvious ticket system and bolt finance onto it. We built the billable record first and made operations serve it, and that single ordering is the difference between a service system that pays for itself and one that becomes another place to look things up.

Technology

What we cannot show

Screens are from the delivered system and include customer names and reconciliation balances as they stood at the time; contract terms, price lists and service margins are not published.

Similar problem?

If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.

Ask about this project