Installed baseNEW
The sale does not end at delivery. The installed base records what each customer has in use: every asset with its serial number, install date, warranty and full service history. Post-sale no longer depends on whoever happened to handle it: you open the account and see what is installed, what is still under warranty and what has already been serviced. That becomes a hook for renewals, maintenance and new sales, all tied to the customer who already lives in your CRM.
- Every installed asset with serial number and install date.
- Warranty control: what is still covered and what has expired.
- Service history per asset, always at hand during support.
- The ticket points to the customer's equipment, the unit with its serial number, not just the model sold, and the equipment's history starts telling the service story.
- Downtime recorded by people, with availability, MTTR and MTBF over the window, and equipment with no downtime recorded read as unmeasured, never as 100%.
Free in Sellio, you only pay for the machine
The installed base comes built in. It is included in the per-user plan; you can try everything free for 14 days.
Support with no data hunt
Open the account, see what is installed, the warranty and the history. Support answers fast and right.
Renewal at the right time
With the warranty in view, you propose the renewal or maintenance contract before the term runs out.
New sales from what already exists
Knowing what the customer has installed opens the upgrade and replacement conversation without starting from nothing.
An availability contract you can actually check
When the contract has a target, the unplanned availability over the window is compared with it and the verdict comes out of the same calculation. Without a target there is no invented verdict.
What the customer has installed, in plain view: no more relying on the salesperson's memory.
Warranty under control: you know what is covered before the customer asks.
A renewal and maintenance hook: every asset is a next commercial conversation.
No telemetry and no dressed-up figure: downtime is recorded by people or from the ticket, and the screen says so instead of dressing the number up.
Every customer asset in one place
Each installed device or product is recorded with serial number and install date, tied to the account. When the customer calls, you already know what they have, with no digging through old email or a lost spreadsheet.
Warranty you keep track of
Each asset carries its warranty term, so you can see at once what is still covered and what has expired. Support decisions stay accurate and contract renewals land at the right time.
History that tells the asset story
Every service is recorded on the asset itself, so the next maintenance starts from what already happened, not from scratch. Post-sale becomes a relationship, not a restart.
The case is about this equipment
The customer calls saying the machine stopped and the next question is "which one?". On the ticket you pick the equipment from the customer's installed base, searching by serial number, which is how they identify it on the phone; only that customer's equipment can be linked, and a ticket with no customer offers no picker at all, and says why. A ticket is about one piece of equipment: an event that takes down ten machines is an incident, which already groups many tickets. Linking the same asset again repeats nothing; switching the asset undoes the previous link and records both sides in each equipment's history, because correcting a choice must not erase the trace that it existed. From then on the equipment's timeline tells the service story: case linked, unlinked and resolved sit next to the installation, the moves and the maintenance. The warranty (active, expiring, expired) and the service contract show up before you open your mouth to the customer, and moving the equipment records where it went, so the location history is the reading of those moves, not a field that forgets the past. On the account page and in the console, the account's equipment shows up with the risk of each unit.
Downtime, availability and life cycle
A contract promising 99% availability was a sentence; now it is a calculation. Downtime is opened and closed by people, or from the ticket, planned or unplanned: there is no telemetry and no machine signal here, and the screen says that out loud. The same equipment is never down twice at once, overlapping stoppages are merged before being added up (availability never goes negative), a stoppage that crosses the month counts in each month only that month's hours, and a stoppage in progress counts up to now, so the number does not improve on its own while the machine is down. Availability comes with the planned share separated from the unplanned one, because a maintenance window agreed with the customer is not a broken promise, and it is the unplanned share that is compared with the contract target. MTTR and MTBF stay empty without enough samples: an MTBF from a single failure is a guess dressed as a measurement. The life cycle has five states: active, in maintenance, in RMA, retired and written off; written off does not come back, because writing off is an accounting fact, and the way back is registering a new asset with the lineage of the old one. Replacing retires the old unit and creates the new one inheriting account, contract and location, with an event on each side pointing at the other. Criticality, age, repeated failures, coverage and measured availability add up to an explainable risk, and the engine states what it had to assume for lack of data. Next actions (end the downtime, close the open case, renew warranty or contract, schedule maintenance, propose a replacement) only appear when they can be acted on: maintenance is only suggested when you say how many months there are between services, and replacement only with a measured high risk, never by age alone.