設置ベース新着
販売は納品で終わりません。設置ベースは、各顧客が使用中のものを記録します。すべての資産をシリアル番号、設置日、保証、完全なサービス履歴とともに管理します。アフターセールスは、たまたま対応した担当者に依存しなくなります。アカウントを開けば、何が設置されているか、まだ保証中のものは何か、すでにサービス済みのものは何かがわかります。これが更新、メンテナンス、新規販売のきっかけとなり、すべてはCRMにすでに存在する顧客に紐づいています。
- 設置されたすべての資産を、シリアル番号と設置日とともに。
- 保証管理：まだ有効なものと、期限切れのもの。
- 資産ごとのサービス履歴を、サポート時に常に手元に。
- 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%.
Sellioでは無料。お支払いはインフラ利用分だけ
The installed base comes built in. It is included in the per-user plan; you can try everything free for 14 days.
データ探しのないサポート
アカウントを開けば、設置されているもの、保証、履歴がわかります。サポートは速く、正確に応答します。
適切なタイミングでの更新
保証を把握した上で、期間が切れる前に更新やメンテナンス契約を提案できます。
既存資産からの新規販売
顧客が何を設置しているかを把握することで、ゼロから始めることなくアップグレードや交換の会話を切り出せます。
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.
顧客が何を設置しているかが一目瞭然。営業担当者の記憶に頼る必要はもうありません。
保証を把握：顧客が尋ねる前に、何が保証対象かがわかります。
更新とメンテナンスのきっかけ：すべての資産が次の商談につながります。
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.
すべての顧客資産を一元管理
設置された各デバイスや製品は、シリアル番号と設置日とともに記録され、アカウントに紐づきます。顧客から連絡があったとき、古いメールや紛失したスプレッドシートを掘り返すことなく、顧客が何を持っているかをすでに把握できています。
追跡できる保証
各資産は保証期間を持つので、まだ有効なものと期限切れのものを一目で確認できます。サポートの判断は正確に保たれ、契約更新は適切なタイミングで実現します。
資産の履歴が語るストーリー
すべてのサービスは資産そのものに記録されるので、次のメンテナンスはゼロからではなく、すでに起きたことから始まります。アフターセールスは、やり直しではなく関係になります。
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.