Standard operating procedure: Verifying on-call contact configuration and email delivery via Case Manager

This document outlines the protocol for schools to review contact information, validate phone numbers, and test email delivery configurations for Securly’s On-Call (OC) product. Following these procedures ensures system accuracy while maintaining critical life-safety workflows.

1. Policy mandate & escalation framework

Mandatory testing environment: Conduct all contact verification and email communication testing exclusively through the Securly Case Manager platform. Testing directly in the live On-Call product environment is strictly prohibited under standard operating conditions.

Operational rationale: The Securly On-Call analyst team monitors high-risk alerts in real time to support students in crisis or distress. Conducting configuration tests in the active On-Call pipeline divides valuable analyst time and diverts their focus from urgent student emergencies. Maintaining the integrity of the On-Call queue is crucial to ensure immediate responses for at-risk students.

Escalation and exceptions: If an institutional leader or administrator believes additional testing in the live On-Call environment is necessary for establishing deployment confidence, they must submit a formal request. Administrators should contact Kathleen Boehle, Director of On-Call (kathleen@securly.com), to present a detailed operational case for live-queue testing. These requests will be reviewed on a case-by-case basis and are strongly discouraged to ensure operational safety.

2. Reviewing contact setup and phone numbers

Case Manager provides access to the active database used by On-Call analysts. Reviewing data here ensures that personnel records, telephone numbers, and notification paths align with what an analyst handles during an escalation.

Protocol for accessing contact details:

1. Log in to the Case Manager interface.

2. Open a relevant student case record from the case feed.

3. Access the contact details pane by clicking the **Contact** option in the bar at the top of the right-hand panel. 

4. Thoroughly audit the listed phone numbers for accuracy. Consider sending a text to those numbers from your own device to ensure they work properly.

5. Verify readiness: The interface dynamically adjusts to show the specific contacts who are authorized and available for that school at that date and time. Note any schedule changes to ensure emergency routing matches expectations.

3. Testing email delivery to authorities and parents

To confirm that notification pathways are operational without impacting the live On-Call analyst queue, administrators should test email alerts directly from Case Manager. This ensures contacts receive standard notifications accurately.

Protocol for sending notifications:

1. Open an active or designated configuration test case in Case Manager. Click on the **Send Email** link in the bar at the top of the right-hand panel.

2. In the panel that appears on the left, you can create your email alert and send it.

3. Select **School Representatives** to receive the email.

4. Coordinate with the recipients to confirm receipt of the email. Verify that the email was delivered successfully, did not go to junk/spam folders, and accurately conveys the automated student safety context.

4. Test account & case protocols 

To maintain data integrity and prevent false alarms in critical safety pipelines, all configuration testing must strictly follow these guidelines:

• No live student accounts: Administrators must NOT use regular student accounts for testing Securly's On-Call product.

• Clear case identification: Any case record used for verification or configuration testing must be explicitly labeled as a "Test" in the Case Manager platform.

• Identifiable test accounts: The email address linked to the profile or used during testing must clearly indicate that it is a test account (e.g., test-admin@school.org).

• Explicit content disclaimers: The content of the activity must state that it is a simulated test to avoid accidental escalation or confusion.

  • Doc titles: All test documents must start with a clear bracketed prefix.
    Required format:
    [SECURLY TEST - NO EMERGENCY] [Document Name]Example:
    [SECURLY TEST - NO EMERGENCY] Simulated Journal Entry

  • Email bodies: The first line of any test email must include a clear, capitalized warning.
    Required format:
    *** SECURLY SYSTEM TEST — NO STUDENT IN DISTRESS — DO NOT ESCALATE ***

  • Searches: When entering search queries in a browser to test keyword flagging, the search must clearly indicate it is a test along with the flagged term for reviewers to see the context.
    Required format:
    SECURLY TEST SEARCH: [insert search term]Example:
    SECURLY TEST SEARCH: how to tie a noose

  • Chats: Any simulated chat messages (via Google Chat, Teams, AI, etc.) must begin with a test disclaimer to prevent misinterpretation.
    Required format:
    [TEST CHAT - DISREGARD]Example:
    [TEST CHAT - DISREGARD] I might kill myself today.