Partner Overdue and Recovery Process Guide

Purpose

This partner-specific operational guide defines the local process for overdue, recovery, and escalation actions for DASH PBDA Device Loan Program devices. It is based on and intended to align with the approved Overdue & Recovery Standard Operating Procedure DASH PBDA, January 2026. It does not replace the approved SOP, Master Policy, or other governing program documents. In the event of any conflict, the approved SOP and governing program documents control.

Scope

This guide applies to partner staff managing device checkouts, due reminders, overdue follow-up, and coordination with KINBER for escalation and recovery actions. It summarizes partner responsibilities and local workflow only. It does not restate every control, exception, or compliance requirement in the approved SOP.

Core operating principle

Partners use their local system alongside KINBER’s systems to manage day-to-day Device Loan Program operations. Partner staff manage borrower-facing reminders, circulation activity, and overdue tracking through their local system, while KINBER maintains program oversight, confirms escalation decisions, and coordinates any remote lock, loss designation, or formal recovery action. HubSpot remains KINBER’s authoritative system of record, but local partner systems are also relied upon for operational execution and day-to-day program management.

Systems of record and roles

Shared operating model

• The Device Loan Program is managed through both KINBER systems and the partner’s local system.
• HubSpot is KINBER’s authoritative system of record.
• The partner’s local system is also relied upon for operational execution, especially for circulation, notices, and local tracking.
• Records across both environments should remain aligned.

Partner local system

• Used for circulation activity, due dates, borrower-facing reminder notices, and local tracking.
• Used to run overdue reports and identify items that cross escalation thresholds.
• Serves as an operational management tool for the partner.

HubSpot

• Remains the DASH program system of record for KINBER.
• Used by KINBER to document status, escalation, recovery actions, and program-level tracking.
• Supports KINBER oversight even when day-to-day actions occur through the partner’s local system.

Dataprise

• Executes remote lock or wipe only when requested by KINBER.
• Does not initiate borrower communication or recovery decisions.

Required documentation and audit trail

Because the program is managed across both the partner’s local system and KINBER’s systems, partner staff must ensure that key borrower notices tied to overdue and recovery thresholds are copied to the KINBER operations inbox for visibility and audit traceability.

• Preferred approach: CC dashsupport@kinber.org on overdue and escalation-related notices sent through the local system.
• If CC is not possible: forward the notice to dashsupport@kinber.org on the same day it is sent.

Standard escalation cadence

The partner process should align to the standard DASH recovery cadence below.

Partner workflow

1. Checkout and due date setup

• Partner staff check out the device through the local system.
• The due date must match the approved DASH loan period.
• Borrower contact information must be accurate at checkout.
• Partner and KINBER records should remain aligned so the local system and HubSpot reflect the same device status.

2. Due reminders and early overdue follow-up

• The partner’s local system sends due and overdue reminders according to local configuration.
• Partner staff monitor overdue reports and identify devices approaching escalation thresholds.
• KINBER should be copied on notices tied to overdue and escalation activity.
• Where needed, partner staff and KINBER should reconcile status across the local system and HubSpot.

3. Threshold-based escalation

• Once a device reaches a DASH escalation threshold, partner staff notify KINBER.
• Partner staff should include the borrower name, device ID, due date, current status, and actions already taken.
• KINBER determines whether the next escalation step should proceed.

4. Remote lock coordination

• Partner staff do not request remote lock directly from Dataprise.
• KINBER reviews the case and, when appropriate, submits the request to Dataprise.
• Any remote lock action must be documented in the program record.

5. Lost device determination

• If the device remains unreturned through the required threshold, KINBER determines when to mark it as lost.
• Partner staff provide the full communication history and any attempted outreach.
• KINBER opens and documents the replacement or recovery case.

Exceptions and special cases

• Hardship pause: Site liaisons may grant a one-time pause of up to 14 days for borrowers facing hardship. Record the start and end dates in the appropriate partner and KINBER program records, including HubSpot, and notify KINBER operations.
• Returned damaged: If a device is returned damaged, complete the required damage documentation and notify KINBER. KINBER will determine the next steps for warranty, accidental-damage protection, or other recovery handling.
• Theft reported: If a borrower reports theft, encourage them to file a police report and share the incident number if available. Notify KINBER promptly so the case can proceed through the required lock and recovery process.
• ADA and language access: Offer reasonable accommodations and language assistance at every contact step, consistent with the approved SOP and applicable program requirements.

Partner staff action table

Minimum information to share with KINBER

When notifying KINBER about an overdue or recovery case, include:

• Borrower name
• KINBER Device ID
• Checkout date
• Due date
• Current overdue status
• Reminder notices already sent
• Any phone or email outreach attempted
• Any known borrower response

Communication standard

Partner communications should remain clear, factual, and consistent with the approved DASH borrower terms. Messages should:

• State that the device is overdue.
• Direct the borrower to return the device promptly.
• Explain when borrowing privileges have been suspended, if applicable.
• Explain when further program action will occur, if applicable.

Key guardrails

• Partner staff should not independently mark a device as lost without KINBER review.
• Partner staff should not request remote lock or wipe directly from Dataprise.
• All escalation actions should align with the standard DASH cadence unless KINBER approves an exception.
• HubSpot remains KINBER’s authoritative system of record even when local partner systems are used for daily operational management.
• Partners are expected to use their local system alongside KINBER processes, not in place of them.
• When there is a discrepancy between records, partner staff should notify KINBER so the case can be reconciled.

Implementation note