Riyan Technolabs

Everything after the sale, tracked in the same system that sold it

Businesses that install, service, and maintain what they sell 8 min read

Selling the product is the part most systems cover. Installing it, honouring the warranty, servicing it on schedule, renewing the contract and collecting for the work - that half usually lives in spreadsheets, message threads, and the service manager's memory.

The problem

Once the invoice is raised the trail goes cold: nobody can say what was installed where, what is still under warranty, which parts left with which technician, or which contracts are about to lapse.

What we build

  • Installation to renewal chain
  • Warranty and AMC contracts
  • Technician app and visit proof
  • Van stock and field cash
  • Automated customer updates

Most business systems treat the invoice as the finish line. For anyone who installs, services, or maintains what they sell, it is closer to the halfway point. The equipment still has to be commissioned. It carries a warranty somebody has to honour. It needs servicing on a schedule, parts get replaced, contracts come up for renewal, and money often changes hands at the customer's door rather than in a bank.

That second half is usually the part with no system behind it, which is awkward, because it is also where the margin and the retention live.

Where the trail goes cold

  • Nobody can say what was installed at a given site, or when, without asking someone who was there
  • Whether a repair is under warranty is settled by finding the original invoice, if it can be found
  • Services due under a contract are tracked in a spreadsheet only one person maintains
  • Parts leave the warehouse with a technician and stop being tracked from that moment
  • Cash collected at the door is reconciled from memory at the end of the day
  • Contracts lapse quietly, and the first sign is a customer who has stopped calling

Each of these is survivable on its own. Together they mean the years after the sale - the most profitable part of the relationship - are the part of the business with the least visibility into it.

Why bolting on a service tool does not fix it

The obvious answer is a dedicated field-service application, and there are good ones. The difficulty is that they start from an empty database. Yours already knows the customer, the exact product variant, the stock in each warehouse, and the accounts those transactions post to. The service tool knows none of it, and every one of those facts has to be copied across and kept in step.

  • Two customer records to reconcile, with a sync job standing between them
  • Warranty status the service tool cannot determine on its own, because the sale lives elsewhere
  • Parts consumed on site that never reduce the stock the ERP is reporting
  • Service revenue and cost arriving as a monthly import rather than as entries in the books
  • A second set of users, roles, and permissions to administer and keep aligned

Building service into the ERP removes the integration work entirely, because there is nothing left to integrate. The ticket points at the same customer record the sale did, consumes from the same stock, and settles into the same accounts.

The chain we build

The sale is the start of the service record

A delivered order can generate the service schedule that follows it: the installation visit first, then each service due under the terms it was sold on. Every scheduled visit carries the customer, the specific product variant, the date it falls due, its number in the sequence, and whether it sits under warranty or under a contract.

The link back to the originating order stays in place. "What did we sell this customer, and when?" is answerable from the service screen rather than by going back through the sales module.

Planned work and reported problems meet in one queue

Installations, scheduled maintenance, complaints, and repairs all become tickets, distinguished by type rather than by which system they happen to live in. A scheduled service becomes a ticket when it falls due; a customer complaint becomes one the moment it is logged. Both then move through the same states, carry a priority, and are assigned to a technician the same way - so the team works one queue instead of a calendar plus an inbox.

The visit is where stock, labour, and proof come together

Each visit records who attended, when, what work was performed, and which parts were fitted, with every part flagged as warranty or chargeable. Location and a photograph can be captured at the point of work, so a completed job is evidenced rather than asserted.

The parts come off that technician's own stock. Treating a technician as a stock-holding location in their own right - rather than as a gap between the warehouse and the customer - is the small modelling decision that keeps the warehouse figure honest. Every movement is typed: issued by the office, used on a ticket, returned, or adjusted after a count. A discrepancy becomes a question about one entry instead of about the whole month.

Billing that already knows what is covered

Because the sale, the warranty terms, and the contract all sit in the same database, the split between covered and chargeable is a property of the record rather than an argument at the door. A ticket carries its labour charge, its parts cost, any discount, the resulting total, and how the customer paid. Contract work draws down the entitlement it was sold with, so a customer on their fourth of four visits is visibly on their last one.

Field cash that reconciles

Money collected on site is recorded when it is collected and carries a status through received, submitted, and settled against a company account, with each technician's outstanding balance derived from those entries rather than maintained by hand. The end-of-day handover becomes a reconciliation against a known figure instead of a conversation about what people remember.

Renewals and updates that fire on their own

Contracts hold their term and their service entitlement, and reminders go out ahead of expiry rather than after it. The events customers care about - a complaint registered, an installation completed, a service closed out, a contract about to run out - already exist in the system as state changes, so templated WhatsApp messages hang off those transitions and run through a retrying background queue with a delivery log. Nobody has to remember to send anything, and a message that fails to send is visible rather than silent.

When this is worth building

If your after-sales work is a handful of callouts a month handled by the same two people, a shared calendar is genuinely enough and we will say so. The threshold is usually one of three things: you cannot answer a warranty question without digging, your service revenue is not visible next to your product revenue, or renewals are being lost to nothing worse than a missed date.

The reason it tends to be worth doing is that a business which can tell a customer exactly what it installed, when it was last serviced, and what is covered is competing on something most of its competitors cannot see, let alone match.

What changes

  • A unit's whole history - sale, installation, every visit, every part - sits on one record
  • Warranty or chargeable is decided by the system, not argued at the customer's door
  • Parts fitted on site come off the technician's own stock, so the warehouse figure stays honest
  • Service revenue and cost report next to product revenue, not in a separate monthly import
  • Contract renewals surface before they lapse, and customers are updated without anyone remembering to