seubert-claims/dev/Seubert-Claims-LukeBillman.md

Key Outcomes

The meeting resolved critical issues with disappearing tasks and established a comprehensive solution for handling client renewal dates. All tasks prior to April 1, 2026 will be marked complete to clear historical backlog, and a new client-level renewal date field will be implemented to ensure consistent task generation across different renewal group configurations.

Decisions Made

Task Visibility and Historical Data

• Mark all tasks before April 1, 2026 as complete to eliminate the backlog of 599+ overdue tasks that were causing confusion across user dashboards
• Standardize overdue task definition across all system views (tasks page, manager page, and workload page) to mean: past the due date, not marked as N/A or completed, with no lower bound restriction

Client Renewal Date Logic

• Add a "Client Renewal" date field at the client level that will be editable by managers and serve as the source of truth for client-level tasks
• Implement automatic date suggestion logic using the following priority: (1) default/starred group renewal date, (2) if only one group exists, use that group's date, (3) if only individual policies exist, use policy date
• Allow manual override of the suggested client renewal date during client setup to accommodate complex scenarios like transportation clients with multiple renewal groups

Meeting Cadence

• Establish weekly or bi-weekly recurring meetings short-term to ensure system issues are addressed promptly
• Explore adding in-app functionality for submitting change requests or bug reports that can be quickly triaged as either bugs for immediate fixes or design issues requiring meetings

Issues Resolved

Disappearing Tasks Problem

• Root cause identified: Original 7-day visibility window was removed to address initial backlog, but this caused legitimate overdue tasks to accumulate without being hidden
• Dashboard inconsistencies: Task counts differed between primary dashboard and task dashboard due to three different overdue definitions being applied across different system views
• Example case: Mimi showed 599 past due tasks in one view but only 2 in another view

JG Contracting Renewal Task Generation Failure

• Problem: Client with January 1, 2027 renewal wasn't generating expected claim review tasks in April and August 2026
• Root cause: System was following the June 30 renewal date of a single unassigned policy instead of the January 1 date of the main renewal group containing the bulk of policies
• Why it happened: System used "nearest to year start" logic (default date rule) which selected June 30 as closer to year start than January 1, applying this to client-level tasks
• Evidence: Client-level tasks appeared at 275 days before June 30 (September 28) and 90 days before June 30 (April 1), confirming they followed the wrong renewal date

Group Numbering Confusion

• Issue: JG Contracting's single renewal group was labeled "Group 2" instead of "Group 1"
• Explanation: Group functionality and UI were built on different days, causing inconsistent labeling logic

Technical Implementation Details

Task Status Update Execution

• Bulk update completed: 3,292 tasks with due date before April 1, 2026 and status "not started" were marked as completed
• Logging implemented: Bulk changes are now logged to track why large numbers of tasks changed status
• Potential issue identified: Some tasks that were previously marked complete after April 1 may have been reset to "not started" - requires investigation

Task Source Tracking

• New icon added: Small settings icon appears next to policies on the right side of the screen to show where tasks originated from
• Helps debugging: Allows users to trace which renewal date or policy group generated specific tasks

Client Renewal Date Field Implementation

• Location: Will appear in the client setup screen alongside existing renewal group configuration
• Label: "Client Renewal" to allow future reuse for other purposes beyond just tasking
• Behavior: Auto-populated by logic on client creation but editable by managers at any time
• No automatic overwriting: Once set, the date won't change automatically unless a specific triggering action occurs

Complex Scenarios Addressed

Transportation Clients with Multiple Renewal Groups

• Use case: Clients with auto and motor truck cargo renewing 1/1, but AUCAC and truck broker liability renewing 3/1
• Challenge: System must allow selection of which group's renewal date should drive client-level tasks
• Solution: Manager can manually select the appropriate renewal date during setup, typically following the "big line" (highest premium policy)

Single Policy vs. Multiple Groups

• Single policy scenario: If client has only one policy with no groups, system will use that policy's renewal date
• Multiple groups scenario: System will follow the starred/default group's renewal date
• Override capability: Regardless of automatic selection, managers can change the client renewal date if business logic dictates otherwise

Pending Confirmation

• Task reset investigation needed: Verify whether tasks completed after April 1, 2026 were incorrectly reset to "not started" during the bulk update
• Sync date range behavior: Confirm that policy syncs only capture policies within the specified date range (e.g., a policy starting 8/1/25 expiring 8/1/26 would be missed if sync runs for 1/1/26-12/31/26)

Technical Specifications

Overdue Task Definition (Standardized)

• Criteria: Task is overdue if all of the following are true:
  • Due date is before today
  • Status is NOT "N/A"
  • Status is NOT "Completed"
  • No lower bound date restriction (perpetual visibility)

Task Generation Logic Hierarchy

1. Client-level tasks: Follow the client renewal date field
2. Group-level tasks: Follow their specific group's renewal date
3. Policy-level tasks: Follow individual policy renewal dates

Default Date Rule Logic (Pre-Fix)

• Original behavior: Selected renewal date nearest to start of year across all policies and groups
• Problem: Did not account for which policies/groups were primary or contained bulk of coverage
• New behavior: Will populate suggested client renewal date but allow override

Action Items

• Lawrence: Implement client renewal date field in client setup screen with auto-population logic and manual override capability
• Lawrence: Investigate and resolve task reset issue where completed tasks after 4/1 may have been changed to "not started"
• Lawrence: Update sync date range to clearly indicate which policies will be captured based on effective/expiration dates
• Luke: Set up weekly or bi-weekly recurring meeting with Lawrence to review ongoing system issues
• Luke: Review task counts across all users to verify the April 1 bulk completion resolved dashboard inconsistencies

Open Questions

Task Visibility After Bulk Update

• Why are some tasks showing different statuses than expected after the bulk completion of pre-April 1 tasks?
• Are there any completed tasks from April 2026 onwards that were incorrectly reset?

Sync Functionality

• Does the sync date range need to be adjusted to capture policies with effective dates before the sync year but expiration dates within it?
• Should sync default dates be modified to be more inclusive of cross-year policies?

System Behavior Notes

Task Page vs. Dashboard Discrepancies (Pre-Fix)

• Tasks page: Counted all overdue tasks with no lower bound
• Manager page: Used configurable overdue window (last 30 days only)
• Workload KPI: Counted all tasks including unassigned ones
• Result: Same user could see vastly different overdue counts depending on which view they accessed

Renewal Group Star Functionality

• Purpose: Star indicates the default renewal group that should drive client-level task generation
• Previous assumption: System was following starred groups for client-level tasks
• Actual behavior: System was using "nearest to year start" logic instead, ignoring the star designation

Policy Sync Date Range Default

• Current behavior: Sync defaults to current calendar year (1/1/26 - 12/31/26)
• Limitation: Policies with effective dates in previous year but expiration in current year will be missed unless date range is manually adjusted

Next Meeting

• Frequency: Weekly or bi-weekly to be scheduled
• Topics: Continue working through system functionality issues and enhancements
• Participants: Luke, Lawrence, potentially Dawn and Christy as needed