Bill Templates Review

## **Summary** The meeting consisted of two primary segments: an initial internal team sync focused on ongoing technical development tasks, followed by a strategic discussion in preparation for a crucial client call aimed at securing a major year-end deal. ### **Internal Development Updates** This section covered the status of various engineering and data-related projects currently in progress. - **Build Template System and Tracking:** Work is underway to add tracking for template creation, though a decision was made to continue allowing creations for now. The next major step is to develop a feature allowing operators to assign specific build templates to bills, which will be essential for data enrichment. A foundational UI page has been created to display structured JSON build template data, which will serve as a base for future features, including filtered views by vendor, client, and client account. - The immediate task is to finalize and deploy the tracking mechanism for template creation. - A new, dedicated page is planned to allow filtering of build template data by vendor, client, and client account number, pulling information directly from the SQL database to show all related service accounts, meters, and line items. Performance optimization for database queries is a noted concern. - The existing UI for viewing per-bill template data is considered valuable for debugging and will be retained, with potential future integration into individual bill details. - **Power BI Reporting and Vendor Management:** Updates were provided on the deployment of a Power BI report and work on a vendor management feature. - A Power BI report named "System Status Bills" has been redeployed to the production service, with minor changes pending. - For ticket PS132, a new "BD Enrolled" field has been successfully added to the edit vendor form. The requirement for this setting to be "filterable in various areas" was clarified to mean adding a filter (similar to the existing Active/Inactive filter) on the vendor management page, which has been implemented. Extending this filter to other reports is a potential future step. - **Report Request for Closed Accounts:** A new report was requested to identify client-vendor accounts that have been marked as final or inactive in the legacy data services (DS) system. This is needed to avoid spending processing time on closed accounts, especially with the upcoming closure of a specific client's accounts. - This will likely be created as a separate report to maintain performance, rather than integrating it into an existing one. - The team will verify if the necessary "inactive" timestamp data is already being stored. ### **Preparation for Critical Client Call** The discussion shifted to preparing for an imminent call with a key client (Yori), where the success of a significant pending deal is at stake. - **Presentation Strategy and Objectives:** The goal of the call is to instill confidence and facilitate the signing of a major deal before year-end. The presentation will cover recent work for three specific clients: Hexpo, St. Elizabeth, and Munson. - The update will be presented directly by the project lead, who is closest to the technical details. - The narrative will focus on issues identified, short-term fixes applied, and the long-term solutions being implemented. - **Client-Specific Data Correction Status:** Progress on correcting data issues for the clients in question was reviewed. - **Hexpo:** A comprehensive overhaul of all accounts has been completed. - **St. Elizabeth:** Data corrections are nearly complete, pending resolution for one account with missing historical data. - **Munson:** A review based on previously identified issues will be finished imminently. - The next planned step is to perform the same comprehensive "sweep" exercise done for Hexpo on St. Elizabeth and Munson accounts, though this is scheduled for after the holidays. - **Communication on System Validations:** A key point of discussion was how to communicate the state of system data validations. - It was confirmed that while some validations had been relaxed in the past to process bills faster, this had not been explicitly communicated to the client. - The strategy for the call is to state that new validations are being *added* to improve data quality, which aligns with the client's stated preference for correctness over speed. This is seen as a way to build confidence without delving into past changes. - **Outstanding Client Requests and Quick Wins:** Several other client requests were highlighted as potential topics or opportunities. - **Bill Health Report:** An investigation is needed into why certain accounts missing usage data are incorrectly showing a "green" healthy status instead of "orange." This is expected to be a point of discussion. - **Multi-Vendor Selection:** A long-standing request for a toggle or multi-select dropdown to assign multiple vendors or commodities to a single bill was discussed. While not a current priority, if it is a relatively simple fix, implementing it could serve as a valuable "quick win" to demonstrate responsiveness. - **Future Onboarding Process:** There was consensus on the need to review and improve the onboarding process for new customers to prevent recurring data issues, emphasizing better upfront organization and setting realistic expectations about data manipulation within the system.