A service call arrives. Is it covered by the agreement, still under manufacturer warranty, explicitly excluded, or billable? In most contracting businesses that question is answered by whoever has been there longest — and answered wrong often enough to matter, in both directions: work given away that should have been billed, and customers billed for work that was covered.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- Agreement and warranty repository — the obligations in one system rather than a filing cabinet.
- Covered assets and service frequencies — exactly what is under contract, per site.
- Entitlements and exclusions engine — the fine print, made operational.
- Response commitments and scheduling rules — SLAs that actually drive dispatch.
- Covered-versus-billable determination — answered at intake, consistently.
- Renewal pipeline and notifications — renewals surfaced before they lapse.
- Labor and material profitability — per agreement, not just per job.
- Customer and service-system integration — connected to dispatch and invoicing.
The Money Is in the Determination
Getting covered-versus-billable right on every call is worth more than most efficiency features, because it corrects a leak that runs continuously in both directions. It also removes an argument with the customer, which is worth something on its own.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- Microsoft 365 Business Solutions — Often built on tools you already license: Microsoft 365 business solutions.
The Dates Are the Hard Part
Before any entitlement engine can answer a question, it has to know when coverage started. That is where these projects stall. Manufacturer warranty may run from shipment, from installation, from commissioning or from substantial completion, and those dates can sit far apart on a construction job. Service agreements may renew on the anniversary of signature or on a fiscal date the customer picked. Extended coverage bought later carries its own clock.
Getting the dates into one place, each labeled with which event it represents, does more for the covered-versus-billable question than any amount of workflow. It is also work you can start without waiting for software.
The Software Is Unfinished; the Discipline Is Not
The Contract, Warranty and Service Agreement Manager is unfinished. You cannot buy it, license it, pilot it or schedule it. What is available now is the discipline underneath it: a single repository, structured dates, and reminders that fire before a renewal window closes.
A repository like that can often be built on tools a business already licenses. Whether SharePoint and Power Automate can carry yours depends on what your tenant actually entitles, which is the first question our Microsoft 365 Business Solutions work asks.
Manufacturer Claims Are a Separate Workflow
Covered-versus-billable has a third branch that gets skipped: work covered by a manufacturer, where you are owed a part and sometimes a labor allowance. Recovering it requires a claim, a serial number, a failure code and a submission inside a window.
It is easy for this to go unclaimed, because the technician fixed the problem and moved on and nobody opened the claim. Whatever system you use should treat a manufacturer claim as a task with a deadline and a named owner, the same way it treats an invoice.
Every Determination Needs an Exception Path
No entitlement engine will resolve every call. Contracts contain language written by lawyers for a future dispute, not for a dispatcher taking a call before the office opens. The useful design admits that: the system offers a determination and a confidence level, and ambiguous cases route to a named person with the contract language on screen.
A system that always returns a confident answer will eventually return a confident wrong one, and the customer will remember that call for a long time.
What to Do Before Any Software Arrives
Pull the agreements into one place. Record start dates, renewal dates and the event each date represents. Note per site what equipment is covered and at what frequency. List the exclusions that come up in arguments.
That inventory is the input to any system you eventually choose, ours included. It also takes the fine print out of folklore held by whoever has been there longest, which is worth doing whether or not software ever arrives.
Frequently Asked Questions
What is the Contract, Warranty and Service Agreement Manager, and what is it not?
The clearest definition is a negative one. It is not a dispatch board, not a work order system, and not an accounting package, and it is not designed to replace a CRM or an ERP, own the customer master, or produce invoices. It is designed as an entitlement layer that sits beside those systems and returns one structured output they can act on. That boundary matters for scoping, because anything that is really a scheduling, costing or billing feature belongs to the system that already owns it. It is a concept under development and cannot be deployed today.
What has to already exist on our side for it to be useful?
Three things are usually the real constraint, and none of them are software. Equipment has to be identified consistently enough to match a covered-asset list, which in practice means serial numbers and site identifiers that mean the same thing in two systems. There has to be a point in your intake where a call is already recorded and can carry one more field, because a determination that lives only inside the entitlement tool changes nothing. And one person has to own the exclusion questions the engine is designed to escalate, with the authority to make that answer stick, so the same clause is not re-argued on the next call.
How is a rollout designed to proceed, in order?
The design assumes data first and switching on last. Agreements and their dates load first. Then the covered-asset list is built per site, matched against whatever asset or equipment records already exist, and reconciled where the two do not agree, which is where this kind of data work usually stalls. Exclusions are encoded as rules only after that, since an exclusion rule is meaningless without an asset to attach it to. Then the engine is designed to run in parallel for a period, so what it would have answered can be compared against what the office actually decided, and only then does it feed intake. Renewal handling and manufacturer claims are designed to come last, because both depend on the same dates being right.
How is it designed to integrate with the dispatch and invoicing systems we already run?
As a service that another system calls, not as a second application someone logs into during a call. The design is a request keyed on customer, site, asset and service date, with a response that carries the covered-versus-billable determination, a confidence level, and the clause it relied on. The determination is designed to be written back onto the work order as a field, so dispatch and billing read it where they already look. The join is the hard part: integration depends on a stable key across systems, and where existing records carry no asset-level identity, the match has to be made at site level first and tightened as the asset data improves.
Who would be able to see and change entitlement data?
Read and write are designed to be separated. Reading a determination is something dispatch, technicians and billing all need. Changing a coverage term, an exclusion rule or a date is for a much smaller group, because those edits silently change every future answer. An edit to an agreement record is designed to be an auditable event with a timestamp, an author and a prior value, for the same reason a billing dispute two years later gets argued from records rather than memory. Identity and roles are designed to come from the directory you already operate rather than from a separate user list maintained inside the product.
Where would our data live, and what stays under our control?
Signed agreements stay in the customer's own storage, with the repository holding structured fields and pointers to them, so the documents never become readable only through this system. A full export of the structured side, meaning agreements, dates, covered assets, exclusion rules and the determinations that were made, in a format another system can load, is treated as a design requirement. Where it is hosted and who holds the administrative credentials are designed to be customer decisions rather than fixed defaults.
What would we have to provide, and what would we have to decide?
The decisions are heavier than the inputs. You would have to decide which system is authoritative when two of them disagree about a site or an asset, what the engine may answer on its own versus what it must escalate, and where the confidence threshold sits, since a low threshold routes everything to a person and a high one buries the cases you most wanted to see. You would also have to decide how a manufacturer claim window is counted when the failure date and the service date differ, because that choice determines which claims the system flags as still open. What you provide is narrower: the agreements, the dates, the per-site asset and frequency detail, and access to the systems it is meant to talk to.
What happens when an agreement is amended in the middle of its term?
This is the case that breaks simple designs, so it belongs in the design from the start. Coverage changes mid-term. Equipment is added or removed, a change order extends scope, an exclusion is negotiated away, a site closes. If the record simply overwrites what it held, a determination made in March becomes impossible to defend in September, because the terms on screen are no longer the terms that were in force. The design is to effective-date every coverage fact, evaluate against the terms in force on the service date rather than the terms in force today, and store each determination with the version of the agreement it was based on. Billing disputes are always about a past date, which is exactly what a system that keeps only current values cannot reconstruct.