Don’t Repair Components Under Warranty… Use Your Data to Alert People!

With more organisations now using Cx Asset Management, the data you hold on components, installations, and warranties is richer than ever. I wanted to write this post to remind everyone and hopefully inform some new folk about just how Cx can help with this kind of thing.

Even with all the asset warranty information stored, many landlords are still paying for repairs on components that are under warranty.

A tenant calls, Customer Services log a repair, the clock starts ticking, a contractor attends… and only afterwards does someone realise:

“Hang on – that door is under a 5-year warranty…”

That’s a huge missed opportunity. And it’s exactly the kind of problem Cx can solve — right at the point the repair is logged, before any costs are committed.

All you have to do is let your data do the shouting.

Why Warranty Alerts Matter

Cx Asset Management already knows:

• What the asset is

• Which components are installed

• Whether there’s a warranty

• Who the contractor is

• When that warranty starts and ends

The key is surfacing that information as an Alert at the exact moment it matters:

• When Customer Services are logging the repair

• When the repairs team are deciding who to send

• When the job could go either to a warranty contractor, defects builder or your standard contractor

Get it right, and you:

• Avoid unnecessary spend

• Reduce invoice disputes

• Protect budgets

• Give staff confidence (“Yes, we have checked the warranty”)

And remember: the cost isn’t just the odd door. Over hundreds or thousands of components across your stock, missed warranty claims can add up to a serious number.

Fixed Alert Descriptions – and Why That’s Fine

One important point about Cx: conditional alert descriptions are fixed for all asset alerts for that type.

That means you’ll generally want a separate alert for each warranty type / contractor combination you care about to really help signpost customer services. For example:

• “Door under warranty – AB Builders”

• “Boiler under warranty – XYZ Heating”

• “Windows under warranty – NewBuild Homes”

  
  

At first that might sound like more work, but in practice:

• Once you’ve written one stored procedure, the rest are just variations on a theme.

• You’re mostly making simple filter wording changes (warranty type, contractor group, etc.), not reinventing the wheel.

So you end up with a neat little library of warranty alerts, each focused on a specific risk/cost area.

The Stored Procedure: Doors Under Warranty with AB Builders

Here’s a real example, using Cx Asset Management data to flag assets with doors still under warranty with AB Builders Ltd.

CREATE OR ALTER PROCEDURE [dbo].[usp_alert_warranty_doors_abbuilders]
AS
BEGIN
    SET NOCOUNT ON;

    SELECT DISTINCT 
          a.AssetId
    FROM Asset a
    JOIN cam.SCSurveyAttribute sc ON a.AssetId = sc.AssetId
    JOIN cam.Warranty w ON sc.SCSurveyAttributeId = w.EntityId
        AND w.EntityType = 70109
        AND w.EffectiveFromDate <= GETDATE()
        AND (w.EffectiveToDate >= GETDATE() OR w.EffectiveToDate IS NULL)
    JOIN dbo.RepairContractor rc ON w.ContractorId = rc.ContractorId
    JOIN dbo.ContactGroupDetail cgd ON rc.ContactGroupId = cgd.ContactGroupId
        AND cgd.EffectiveFromDate <= GETDATE()
        AND (cgd.EffectiveToDate >= GETDATE() 
			OR cgd.EffectiveToDate IS NULL)
    JOIN Lookup l ON w.Type = l.LookupReference AND l.LookupTypeId = 205
    WHERE 
        l.Description = 'Door Warranty'
        AND cgd.GroupName = 'AB Builders Ltd'
END
GO

A couple of key points:

• This example is based on a warranty linked to a survey attribute (SCSurveyAttribute).

• Exactly the same principle works where the warranty is linked to a replacement or other entity — you just adjust the joins.

  
  

If you want to see what the warranties and contractors are, just update the 'select' to bring in some additional columns, but they can't be there when you deploy the final procedure:

    SELECT DISTINCT 
          a.AssetId,
        	 l.Description AS [WarrantyType],
          w.Description AS [WarrantyDescription],
          cgd.GroupName AS [Contractor]             
    FROM Asset a
    

Always test it first, so run this in SQL Server:

EXEC [dbo].[usp_alert_warranty_doors_abbuilders]

It will look like this (with different AssetIds of course):

Once this procedure is in place, you configure an Asset-Based Conditional Alert to use it, like so:

From that point on:

• Whenever a repair is logged against an asset in that result set

• Cx will automatically display the alert telling staff the door is under warranty with AB Builders Ltd

  
  

No one has to remember. The system does the thinking for them.

Hosted by Civica? No Problem.

If you’re Civica-hosted, you can’t just deploy the stored procedure yourself.

In that case:

1. Build and test the procedure. (or if you're not sure send it to me and I'll tell you if it will work)

2. Once you’re happy it returns the right AssetIds,

3. Send the final version over to Civica to apply.

Realistically, that’s only a few minutes’ work for them once they’ve got a working script.

Alerts That Lift Themselves

One of the nicest things about doing this data-driven:

• The alert will automatically lift when the warranty expires.

Because your procedure respects EffectiveFromDate and EffectiveToDate, as soon as:

• EffectiveToDate passes, or

• The warranty record is updated

…the asset simply drops out of the result set, and the alert disappears from Cx without anyone needing to manually tidy things up.

Update the attribute, warranty, or contractor and the effects ripple straight through to the alert.

That’s the beauty of using the data properly instead of relying on notes, leaving it buried 5 screens down, or worse - memory.

Attribute-Based or Replacement-Based – It Doesn’t Matter

This example uses a warranty linked to an attribute, but the same pattern works just as well when the warranty is linked to a replacement component or Equipment.

• Change the joins

• Keep the warranty filters and contractor join

• Keep returning just the AssetId for the alert

The logic stays the same:

“Give me all the assets where this thing is still in warranty, with this contractor, right now.”

From there, Cx Asset Management and Repairs do the rest.

Solving the Problem Where it Actually Happens

The key is where you solve the problem.

The costly mistake happens:

• At the point the repair is logged

• When the job is raised and the clock starts ticking

  
  

That’s where the decisions matter and therefore where the alert needs to appear.

If staff see, right on screen:

“Door under warranty – AB Builders Ltd. Do not order standard repair.”

…they can instantly make a better decision:

• Redirect to the warranty contractor

• Advise the tenant appropriately

• Avoid a chargeable visit you never needed to book

As more organisations roll out Cx Asset Management, this is exactly the kind of joined-up, practical value you can unlock — not by buying another module, not by ditching a system because there's a few bugs, or you've seen something shinier!...but by using the data you already have.

Final Thoughts

Missed warranties are one of those “hidden” costs that rarely show up as a single big number on a report — but they quietly drain budgets over time.

With a simple stored procedure and an Asset-Based Conditional Alert, you can:

• Stop paying for repairs on components under warranty

• Let data drive behaviour, not memory

• Ensure alerts lift automatically when warranties end

• Scale the pattern across multiple warranty types and builders with minimal effort

  
  

Once you’ve got one procedure working, the rest really are easy.

If you’re wondering how far you can push it to join all this stuff up — or if you’ve got a particularly messy warranty scenario you’d like to tame — get in touch.

You know me: the harder the challenge, the more I enjoy it. 😄

Oh and if you liked this article be sure to hit the like button down the bottom.