Maintenance & Service

ClientCove's maintenance system gives you scheduled service dates per asset, automated daily reminders to assigned technicians, and a record of every service event in the asset's activity log.

How Maintenance Works

The model is intentionally simple:

1. Each asset has a Last Service Date and a Next Service Date
2. Assigned To and Secondary fields name the responsible technicians
3. A WordPress cron job runs daily at 8:00 AM to check upcoming service dates
4. When a service date is approaching (configurable lead time), the assigned techs get an email + in-portal notification + optional message
5. When the service is performed, the tech (or admin) updates the dates: Last Service Date = today, Next Service Date = next scheduled
6. The activity log records the whole sequence

There's no separate calendar UI for maintenance — the dates live on the asset itself, surfaced in the Asset directory's "Next Service Date" column for at-a-glance visibility.

Service Date Fields

Two ACF date fields drive the system:

Both display in the asset header and on the Details tab. Inline-editable for admin/editor (click the value, pick a date, blur to save).

There's no automatic interval — Next Service Date isn't calculated from Last + interval. You set both manually based on your service schedule (monthly, quarterly, annually, etc.) or based on vendor recommendations.

If you want automated rescheduling (e.g. "always 90 days from last service"), that's a customization layer your team can add via post-save hooks.

Setting a Next Service Date

To schedule the next service:

From the asset workspace

1. Open the asset
2. Click the Next Service Date value in the header (or in the Details tab)
3. Pick a date from the date picker
4. Click outside or press Enter to save

The change is AJAX — saves immediately, logged to activity, and surfaces in the directory's filter.

Bulk setting

The Assets directory doesn't currently expose a bulk "set service date" action — schedule each asset individually, or use the WordPress admin's bulk-edit if you have many assets to schedule.

Via API

The next_service_date field can be updated via the WordPress REST API for assets, useful for scripts that import service schedules from external systems.

Service Notes

The Service Notes field is a free-form textarea visible to assigned technicians. Use it for:

• Specific maintenance procedures for this asset
• Common issues to check
• Vendor support contact info
• Calibration tolerances
• Required tools

When a tech opens the asset to perform service, the notes appear prominently in the Details tab — they're meant to be the first thing the tech sees.

The placeholder text on the field reads:

"Enter maintenance instructions, common issues, or service reminders..."

Assigning Technicians

Two fields drive the assignment:

Assigned To (primary)

The technician with primary responsibility. They're the default recipient of service reminders and the contact for issues with the asset.

Secondary

Backup tech. Receives reminders too (when configured), and can act as a fallback if the primary is unavailable.

Both fields are user-relationship fields scoped to roles that can be assigned (typically Administrator, Editor, Representative, Technician — your portal config determines the exact set).

Who gets the reminders?

The check_asset_service_reminders_daily cron iterates over assets with upcoming service dates and notifies the Assigned To user. Whether Secondary also gets notified depends on your portal's configuration of asset-notification-functions.php.

Automated Service Reminders

A WordPress cron job runs daily at 8:00 AM to check for assets with upcoming service dates.

How the cron is scheduled

// Runs once a day at 8 AM
wp_schedule_event(strtotime('tomorrow 8:00 AM'), 'daily', 'check_asset_service_reminders_daily');

The hook fires check_asset_service_reminders which:

1. Queries all published assets with a next_service_date set
2. Compares each next_service_date against today + the configured lead time
3. For matching assets, identifies the assigned tech(s)
4. Sends notifications via the configured channels (see below)

Cron health

WordPress cron requires regular site traffic to fire (it triggers on page loads). For low-traffic portals, configure a real system cron to hit wp-cron.php every minute or so:

* * * * * curl -s https://yourportal.com/wp-cron.php?doing_wp_cron > /dev/null

Without external triggering, reminders may fire late or not at all on a quiet site.

Lead time configuration

The default lead time (how many days before next_service_date to start reminding) is set in asset-notification-functions.php. Adjust as needed — most setups use 7 or 14 days.

Reminder Delivery Channels

When a reminder fires, ClientCove notifies the assigned tech via three channels:

1. Email

A formatted email is sent to the tech's WordPress profile email. The email includes:

• Asset name
• Asset type
• Client and location
• Next service date
• Service notes (if set)
• A link to open the asset in the portal

The email subject line is something like:

Service Due: <asset name> - <next service date>

2. In-portal notification

A row is created in the user's notification feed (type: service_reminder, action_type: service_due). Appears in the notification dropdown next to the user's avatar.

3. Message thread (optional)

If your portal is configured to also create a message in the conversations feature, a message thread is opened with the tech notifying them of the upcoming service.

All three are best-effort — failure of one doesn't block the others, and each is logged.

Marking a Service Complete

When the technician performs the service:

1. Open the asset workspace
2. Click Last Service Date in the header
3. Set to today
4. Click Next Service Date
5. Set to the next scheduled service (e.g. today + 90 days for quarterly)
6. Add a brief note to Service Notes describing what was done (optional but recommended)

Both date changes are logged to the activity log:

• Last Service Date changed from <old> to <new> by <user> at <timestamp>
• Next Service Date changed from <old> to <new> by <user> at <timestamp>

The technician can also create a ticket for the work performed (or attach the work to an existing ticket) — see below.

Status changes during service

Optionally, change the asset status to Maintenance while the work is in progress, then back to Active when complete:

1. Click the Status badge → set to Maintenance
2. Perform the work
3. Update Last/Next Service Date
4. Click Status → back to Active

This gives at-a-glance visibility ("which assets are currently being serviced?") via the directory's status filter.

Tickets from Service Reminders

The integration with the ticketing system is loose by design — service reminders trigger a notification, not an automatic ticket. To track the work formally:

1. When the reminder arrives, open the asset
2. From the asset's three-dot menu → Create Ticket from Asset
3. The ticket form opens pre-populated with the asset reference, client, and location
4. Add a description (e.g. "Quarterly maintenance for Q2 2026")
5. Submit the ticket
6. Perform the work, log time on the ticket as usual
7. Close the ticket when done
8. Update the asset's service dates separately

The ticket and the asset's date update are independent records — both contribute to the audit trail, and you can cross-reference them in the asset's Tickets tab.

Some workflows prefer auto-creating a ticket from each reminder. That's a simple customization layer if your team needs it — hook into check_asset_service_reminders and create tickets in addition to notifications.

Warranty Tracking

Three additional date fields support warranty awareness:

• Purchase Date — when the asset was acquired
• Install Date — when it was deployed
• Warranty Expiry Date — when the manufacturer warranty expires

These don't trigger automatic reminders by default, but they:

• Display prominently in the Details tab
• Are queryable via the REST API for custom dashboards (e.g. "show me assets with warranty expiring in the next 90 days")
• Surface in CSV exports

For warranty expiry reminders specifically, you can extend the cron to check warranty_expiry_date alongside next_service_date — the underlying notification infrastructure supports it.