48 min read

Acre Dashboard Explanation

Acre Software Task Screenshot

Overview
- Initial Assumptions
- Future Work
README Contents
Shared Calculation Rules
Repository Structure
Internal Dashboard
Lender Dashboard
Mortgage Data Dictionary
User Stories
- Acre Internal Users
- Lender Partners

Overview

Link to GitHub README

I treated this exercise as a way of exploring the various optimal graphics for a wide range of metrics and insights that could be derived from the data.

Initial Assumptions

Two separate dashboards, one for internal users and one for external users:
- Internal users: Acre employees who need to understand the global activity data of lenders.
- External users: Lender partners who need to understand their own performance data.
- External users are not able to see the internal dashboard.
Built as a screen developed within the context of a wider application.
- No header and footer, nor a proper sidebar for navigation
- No login/authentication feature
- Designed for desktop viewports, with limited scaling between small, medium and large desktop screen sizes
Assumed that lender partners do not have access to seeing the lender data of other partners within Acre's system.
Technical stack:
- Built as a Single Page Application (SPA) - ignoring routing for simplicity
- CSV is parsed client-side and mapped into typed domain objects
Time frames:
- "This half" represents the last 6 months of 2025, "This quarter" represents the last 3 months and "This month" represents the last month. In the production app, these would be dynamic and would be based on the current date.
Pipeline stage grouping assumptions:
- Stage 1 (Lead): LEAD - Represents unqualified interest.
- Stage 2 (Recommendation): PRE_RECOMMENDATION, POST_RECOMMENDATION_REVIEW - Groups the adviser's research and advice process.
- Stage 3 (Application): PRE_APPLICATION, REVIEW, APPLICATION_SUBMITTED, REFERRED - Everything from the client agreeing to proceed through to the lender receiving the case. REFERRED sits here because it's still fundamentally an underwriting response to the submission, not a new stage in the client journey.
- Stage 4 (Offer): AWAITING_VALUATION, AWAITING_OFFER, OFFER_RECEIVED - The lender's assessment phase. AWAITING_VALUATION and AWAITING_OFFER are both just waiting states within this phase, and OFFER_RECEIVED is the outcome. Reflects that the client and broker are essentially waiting on the lender throughout.
- Stage 5 (Completion): EXCHANGE, COMPLETE - EXCHANGE and COMPLETE are both conveyancing milestones. They're legally distinct but from a mortgage pipeline perspective they represent the same final phase - the deal is done, it's just a matter of when the keys exchange hands.
- Exit stage: NOT_PROCEEDING - Exit state that can occur at any stage.
- System admin states excluded: IMPORTING, IMPORTED_COMPLETE
Data Assumptions
- IMPORTING and IMPORTED_COMPLETE cases are excluded from metrics as I am assuming these are cases in admin processing and need to be completed in their set up in Acre before categorisation
- I limited the LTV bands at 100% - initially misunderstanding that LTVs could be higher than 100%
- The Pipeline Funnel mode and LTV-focused calculation metrics remove any cases with an LTV greater than 1.5
- Blank lender rows are still included in the market average as they are treated as missing data and not excluded from the calculation.

Future Work

To take this piece of work further, I would do the following:
- Set up some data indicators to help with data quality and validation
- It would then help to exclude certain data to build the most accurate and useful dashboard for the users
- I'd emphasise of ensuring the data is properly populated in the "Data Quality" section
- I'd conduct user interviews with both internal Acre users and Lenders to review the dashboard and gather feedback which key metrics to explore further.
- I'd improve the shared logic of LTV inclusion, ensuring all metrics have the same exclusion logic for LTVs greater than 1.5 after understanding the logic for LTVs higher than 1.
- I'd extend the insights logic, either grouping them onto the Insights tab or distributing banners throughout the dashboard to highlight the insights.

README Contents

Design Decisions and Trade-offs

Why this structure

The structure is designed to answer the highest-value questions for both audiences with minimal friction. For Acre internal users, the priority is a clear market-wide view of volume, funnel progression, and benchmark performance so they can identify platform trends and intervention points quickly. For lender users, the priority is a focused “market vs me” experience that highlights where they over- or under-index against anonymised market baselines.

I prioritised conversion velocity, pipeline progression, and comparative benchmark metrics because they are the strongest practical indicators of operational efficiency and commercial opportunity in mortgage journeys. This also keeps the dashboard decision-oriented: users can move from insight to action (for example, identifying stalled pipeline stages or underperforming segments) without needing raw-data exploration first.

From an implementation perspective, I kept the module as a React + TypeScript SPA embedded within an assumed host application and avoided unnecessary routing/auth complexity for challenge scope. That trade-off improves delivery speed and demo clarity while preserving a path to production hardening (API-backed aggregation, richer navigation, and stronger role/access controls).

Trade-offs

Client-side parsing is acceptable for challenge scope but would not be ideal at higher production volumes. A real-world solution would involve a backend DB (Postgres/BigQuery) rather than client-side CSV parsing.
Charting increases bundle size; heavier tab content is lazy/deferred.
Some benchmark formulas are intentionally simplified for consistency and explainability.
For this challenge, parsing and aggregation are performed client-side; in production, I would move aggregation to API-backed services and use worker-based parsing/background processing to keep the UI responsive at larger data volumes.

Process

I started the task by using Claude to identify the detail behind each header and ensuring that I had a clear understanding of the data and terminology used. I have a lot of domain knowledge to pick up about the mortgage industry although the terminology quickly became obvious to me as I read through the data.

I then wrote up my assumptions from reading the task, stripping back quite a bit of content to bring the scope of the challenge down to just indicate value add for users rather than including all the typical functionality that would be expected in a real application (login, sidebar, footer, etc). I collated context data such as the task information, job description, screenshots from Acre's website for styling reference and fed these to Claude to research and generate a detailed plan of the task and generate initial mock ups.

I wrote some user stories for the task to help guide the development of the app, looking at the data and understanding the context to generate the stories. I then used Claude to tidy these up and best identify the user names.

I ran the plan in Cursor to generate the initial code for the task, reviewing the output on Thursday evening. I then slept on it and reviewed the output again on Friday morning, first committing to GitHub after some minor UI/layout improvements. I spent Friday afternoon setting up further visualisation charts to add to the dashboard.

I double checked that the dashboard values were correct and aligned with the data in the CSV file by converting the CSV into Excel formula and analysing the data using formulas. I checked the data against the dashboard design on Sunday afternoon and made some minor adjustments to the dashboard to ensure that the data was displayed correctly and optimally.

In a working environment, my behaviour towards regular git pushes would change to include more commits and smaller commits to help with code review and collaboration.

On Monday morning I cleaned up the repo and README.md file and committed the final version to GitHub for submission.

Data Quality

Current handling in this implementation

Values in CSV monetary fields are interpreted as pence and converted to pounds for display.
Multiple date/time formats are normalized during parsing to support consistent aggregation and charting. For a production app, I would be working to standardise the data in the database rather than in the application.
Parse quality and missing-data conditions are surfaced in data quality-oriented UI areas.
Outlier filtering is applied for some risk views (e.g. very high LTV exclusions) to avoid misleading summaries.
The "initial_pay_rate" values came in in the format of 454000 which I have assumed to be 4.54% based on realistic rates from the market.

Known data limitations

Important fields have low population in places (especially lender and mortgage value), which affects confidence for some lender-level metrics.
Dataset covers 2025 only, so some year-over-year trend cards show no prior-period baseline.
The market average in lender pages uses selected-period row averages; production logic would require stricter completeness and quality gating.
In a production app, I would validate the data at ingestion and route missing/invalid data such as missing lender rows to a quarantine stream with reason codes and track blank-lender rate as a data quality SLI with alert thresholds.
For the Median Days from recommendation to submission, the value I am using is coming out as 0, as sometimes the recommendation_date is after the first_submitted_date so my definition of this needs to be reviewed with better understanding of the process.

Pipeline stage grouping assumptions

To avoid cluttering the dashboard funnel, I added a grouping for case status, listed below. These could be adjusted to better reflect working assumptions in the production app. Statuses are grouped as:

Stage 1 (Lead): LEAD
Stage 2 (Recommendation): PRE_RECOMMENDATION, POST_RECOMMENDATION_REVIEW
Stage 3 (Application): PRE_APPLICATION, REVIEW, APPLICATION_SUBMITTED, REFERRED
Stage 4 (Offer): AWAITING_VALUATION, AWAITING_OFFER, OFFER_RECEIVED
Stage 5 (Completion): EXCHANGE, COMPLETE
Exit stage: NOT_PROCEEDING
System admin states excluded: IMPORTING, IMPORTED_COMPLETE

Further Ideation

With additional time, user research would guide feature prioritization before implementation. Adding proper discovery to the process will ensure that the features are actually needed and valuable to the users. However, below I have outlined some possible areas for extension.

Product and UX priorities

Optimised Overview tabs to show the most important insights first based on user research.
Optimised data loading between pages to avoid the data being reloaded on every page change.
Accessibility improvements (ARIA semantics, assistive technology support) are identified as a next-step focus area.
Performance and polish improvements would target loading behavior (adding skeletons), tooltips, micro-interactions, and navigation smoothness.

Potential feature extensions

Additional filtering across case type/status and other dimensions for deeper investigative workflows.
More granular export options by chart/table/page instead of only broad exports.
With more time, I would also consider adding extra pipeline analysis, investigating more cases stuck in the pipeline at certain stages to understand why and what can be done to improve the process. For this demo, I have added a few insights to the lender dashboard for cases stalled at submitted to give a feel for the type of analysis that could be done.
If it was known that a lenders entire mortgage case profile was stored on Acre, we could add additional information such as how much total loan value they are committed to.

Data and modelling enhancements desired

Better upstream data completeness and quality controls for key attributes. I began mocking up some data checking functionality in a local Excel file (e.g. if a case is at "PRE_RECOMMENDATION", check that the data has a mortgage value and LTV value), but considered the full implementation out of scope for this challenge.
Visibility of case status immediately prior to NOT_PROCEEDING to improve root-cause analysis. Without this, it can be difficult to understand from the data where the case was lost for further analysis.
Lookup enrichment for organisation, advisor, and case manager to unlock user-personalized analytics.
Currently, the market average used on the Lender dashboard is the average of all rows of the data in the selected period. In a production app, I would use a more sophisticated approach to calculate the market average based on checked and completed data after deeper interrogation of the incomplete data rows.

Shared Calculation Rules

Period scoping: Unless explicitly stated otherwise, dashboard metrics are computed from periodData, where rows are filtered by createdAt within the selected period.
System-state handling: Many denominator-based rates exclude system statuses (IMPORTING, IMPORTED_COMPLETE) via toPipelineStage / isSystemCaseStatus; those rows are not counted as funnel stages.
Date anchors: Several stall/age metrics use a fixed as-of date (2025-12-31) in current implementation, while funnel in-flight warning logic uses today with typicalLifecycleDays.
Value guards: Revenue and mortgage-value sums usually clamp null/negative values to zero; averages typically exclude null values.
LTV guards: Risk metrics generally treat valid LTV as 0 <= ltv <= 1.5, and some funnel/cohort metrics explicitly exclude rows with ltv > 1.5.

Repository Structure

Top-level directories and purpose

src/: Application code (React UI, state wiring, business logic helpers, and types).
public/: Static assets loaded directly by the app, including the CSV data source used in this challenge.
dist/: Production build output generated by Vite
Root config files (package.json, tsconfig*, vite.config.ts, lint/tailwind/postcss configs): Tooling and build/runtime conventions

src/ split by dashboard domain

components/internal/: Internal (Acre-side) dashboard tabs and cards.
components/lender/: Lender-facing dashboard tabs and cards.
components/shared/: Reusable primitives shared by both audiences (KPI cards, filters, shared funnel components, chart wrappers).
components/shell/: Application shell and navigation orchestration (AppShell) that composes views/tabs and lazy-loads tab content.
Why this split exists: It keeps audience-specific behaviour separate while preserving shared UI/interaction consistency across both dashboards.

Data, state, and metric computation layers

context/ (under src): Global app data context (DataProvider) that exposes load status, active period, selected lender, and period model.
hooks/: Data loading lifecycle (useDataLoader) so async parse/filter flow is isolated from presentation components.
utils/: Centralized parsing, normalization, aggregation, and metric helpers (csvParser, aggregations, funnelMetrics, lenderInsights).
types/: Shared TypeScript contracts (MortgageCase, period/metric models) used across UI and utility layers.
Why this split exists: Components stay focused on rendering and interaction while calculation logic remains testable, reusable, and consistent between tabs.

Testing layout and rationale

Shared test support and smoke coverage (src/test/): Reusable fixtures/setup plus cross-feature smoke tests for high-risk shared components. Utility-level tests - Formula and aggregation correctness checks where most business risk lives.

Why the repo is structured this way overall

Audience boundary first: Internal and lender journeys are separated by folder to reduce accidental coupling and privacy-risky cross-use of data views.
Shared building blocks second: Common controls/components/metrics are centralized so both dashboards remain visually and behaviourally aligned.
Change safety third: Tab-level code lives in focused modules and is lazy-loaded by the shell, lowering blast radius for incremental feature updates.

Internal Dashboard

Overview

Internal Dashboard Overview

The Overview screen gives internal users a fast view of platform activity volume and seasonality.

TOTAL CASES (KPI Card)

What it shows: Total number of case records created in the selected period (stats.totalCases). Count of rows after period filtering.
Value to user: Internal teams get a fast view of platform activity volume.

TOTAL COMPLETED LOAN VALUE (KPI Card)

What it shows: Sum of mortgageAmount for cases in completion statuses (EXCHANGE or COMPLETE). Filter completed-status rows and sum positive mortgage amounts.
Value to user: Internal teams can track delivered lending value, not just case count.

COMPLETED CASES (KPI Card)

What it shows: Count of cases mapped to pipeline stage COMPLETION (EXCHANGE or COMPLETE). Calculated: toPipelineStage(caseStatus) === 'COMPLETION' count.
Supporting metric shown under value: Completion rate: X%, where X = completedCases / totalCases for the selected period.
Value to user: Internal teams can monitor conversion outcomes at the end of funnel.

TOTAL REVENUE (KPI Card)

What it shows: Sum of totalCaseRevenue for all rows in period. Add each row's revenue value (total_case_revenue).
Value to user: Internal teams can tie operational activity to commercial outcome.

AVG NET REVENUE PER COMPLETED CASE (KPI Card)

What it shows: Mean netCaseRevenue across successfully completed cases. Sum net_case_revenue for completion-stage cases COMPLETION (EXCHANGE or COMPLETE) / completed-case count.
Value to user: Internal teams can compare efficiency and quality of converted business.

AVG COMPLETION DAYS (KPI Card)

What it shows: Mean days from firstSubmittedDate to completionDate (Typical time it takes to complete a case after submission). Average calendar-day difference across valid submitted+completed rows.
Supporting metric shown under value: Avg days to offer is the average difference of firstSubmittedDate to firstOfferDate.
Value to user: Internal users can detect operational slowdowns affecting broker/lender experience.

DAILY/MONTHLY VOLUME CHART (Chart)

What it shows: Time-series of case created/completed volume with computed linear trend line. Count of cases created/completed by day/month.
Value to user: Internal users can identify momentum shifts and cyclicality quickly.

Internal Dashboard Overview 2

PIPELINE FUNNEL (Chart)

What it shows: Cohort conversion/timing/exit analysis. How a created-in-period cohort progresses through the journey.
How Pipeline funnel is calculated:
1. Build cohort from createdAt in selected period.
2. Exclude IMPORTING / IMPORTED_COMPLETE and ltv > 1.5.
3. Optionally exclude PT (pt = true, default ON).
4. Count milestone reach (recommendationDate, firstSubmittedDate, firstOfferDate, completionDate).
5. Compute:
  - stageConversion = stageCount / previousStageCount
  - cumulativeConversion = stageCount / cohortCount
6. Compute medianDaysFromPrev for each transition after Lead.

Application 0 median days

The median days is 0 for Application because the recommendation_date is after the first_submitted_date so my definition of this needs to be reviewed with better understanding of the process.

Exit analysis : Shows a split of what stage the cases exited at. So 89.4% of the cases exited at Lead, where they had a createdAt date, but then were either marked as NOT_PROCEEDING or had a notProceedingDate before they had a recommendationDate.
- exitRate = exitedCases / cohortCount
- exited-at-stage distribution based on furthest reached milestone before exit.
- How exits are identified: exitedCases are cohort rows where notProceedingDate exists or caseStatus === NOT_PROCEEDING.
- How exited-at-stage is assigned: For each exited row, evaluate milestone dates in order (createdAt, recommendationDate, firstSubmittedDate, firstOfferDate, completionDate) and take the furthest milestone date that is on/before notProceedingDate (or furthest available milestone when no explicit exit date exists). Map that index to pipeline stage and increment that stage bucket.
- How breakdown percentages are calculated: stageExitShare = exitedAtStageCount / exitedCases (denominator is exited rows, not full cohort).
In-flight warning : Shows when selected range end is too recent relative to typical lifecycle; warns that completion may be artificially low.
PT toggle rationale: PT journeys may skip normal progression stages; excluding them improves comparability of standard pipeline conversion metrics.
Value to user: Internal users can separate throughput issues (timing), conversion leakage (stage/cumulative rates), and attrition concentration (exit stage mix) in one panel.

STAGE DISTRIBUTION (Chart)

What it shows: Distribution of cases by pipeline stage. Group by pipeline stage and show shareOfTotal = stageCount / totalEligibleCases.
Value to user: Internal users can see the distribution of cases by pipeline stage.

CASES BY TYPE (Chart)

What it shows: Distribution of cases by normalized case type. Group by case type and divide each count by total cases.
Value to user: Internal teams can align product/ops focus to dominant case segments.

What it shows: Per-lender share of completed-case volume. Which lenders are winning the most completions. Count completed cases per lender / total completed cases.
Value to user: Internal teams can track concentration and partner performance dynamics.

Internal Dashboard Overview 3

LTV DISTRIBUTION (Chart)

What it shows: Share of cases per LTV band. How much business sits in low vs high leverage ranges. Bucket valid LTV values into configured bands and normalize by total.
Value to user: Internal users get a portfolio risk profile at a glance.

LTV bands

I limited the LTV bands at 100% - initially misunderstanding that LTVs could be higher than 100%

MORTGAGE AMOUNT DISTRIBUTION (Chart)

What it shows: Share of cases by mortgage-amount bands. Shows whether business is weighted toward smaller or larger loans. Bucket mortgage amounts into predefined ranges and normalize.
Value to user: Internal users can monitor value mix and potential revenue implications.

What it shows: Single platform-level headline for broker revenue tied to stalled submitted cases. "How much revenue is currently at risk if stalled cases do not progress." Identify application-stage cases above the platform submitted-age median (calendar-day diff between firstSubmittedDate and recommendationDate), then sum totalCaseRevenue across that stalled subset.
Value to user: Internal users get an immediate commercial-risk signal before drilling into detailed tabs.

Stalled cases - 0 median days

The stalled cases are identified as calendar-day diff between firstSubmittedDate and recommendationDate. This is then showing as 0 as some of the cases have a recommendationDate after the firstSubmittedDate, presumably as the recommendation date field was re-updated.

DROP-OFF REASONS (Table)

What it shows: Ranked reasons from NOT_PROCEEDING cases, plus linked volume/value (total_case_revenue). Filter not-proceeding rows, group by reason, sort by count.
Value to user: Internal teams can prioritize root-cause fixes where loss impact is highest.

Product Analysis

Internal Dashboard Product Analysis

AVG TERM LENGTH (KPI Card)

What it shows: Average term length for period rows, displayed in years. Parse and normalize term values to a consistent basis, then compute mean term and present in years.
Value to user: Internal teams can quickly monitor shifts in product duration profile.

REGULATED CASES (KPI Card)

What it shows: Count and share of period cases where regulated is true. How much of platform flow falls under regulated-case scope. regulated case count / total period cases, shown as both absolute count and percentage.
Value to user: Internal teams get an immediate compliance-composition signal.

COMPLETED CASES WITH LINKED PROTECTION (KPI Card)

What it shows: Number and share of completion-stage cases where linkedProtection is true. How many completed cases also attached protection products. Filter completion-stage rows, count linkedProtection = true, and divide by completed-case total for the subtitle percentage.
Value to user: Internal teams can track protection attach outcomes on completed business.

HIGHEST AVG NET REVENUE CASE TYPE (KPI Card)

What it shows: Case type with the highest average net revenue in the period (excluding Other). Compute average net revenue by case type, exclude Other, and select the highest valid value.
Value to user: Internal teams can identify the most commercially efficient case segment at a glance.

What it shows: Distribution of period cases across normalized initial-rate types. Group period rows by normalized initialRateType. Excludes blank values.
Value to user: Internal teams can track product appetite shifts that affect pricing and risk.

CASE COMPOSITION (Panel)

What it shows: Four mini-stat tiles for key composition flags: PT, Consumer BTL, Further advance, Porting. How common each specialist case category is in current period flow. For each flag, count rows where the flag is true and divide by total period cases for percentage.
Value to user: Internal teams can quickly monitor portfolio mix dimensions used in policy and operational planning.

Internal Dashboard Product Analysis 2

CASE TYPE PERFORMANCE (Table)

What it shows: Per-case-type performance rows with volume, completion rate, not-proceeding rate, and average net revenue. In plain terms: Which case types are converting best, leaking most, and generating strongest average revenue.
How it is calculated: Group period-filtered rows by normalized case type, then compute:
- Volume = row count
- Completion rate = completed count / volume
- Not-proceeding rate = not-proceeding count / non-system rows for that case type
- Avg net revenue by case type = sum(net revenue) / volume for that case type
Value to user: Internal teams can compare quality and commercial output across product segments in one place.

BY CLUB / NETWORK (Table)

What it shows: Which clubs/networks contribute the most cases and strongest completion outcomes.
How it is calculated: Group period rows by normalized clubName, then compute:
- Cases = row count
- Completion rate = completed count / cases
- Total loan value = sum(mortgageAmount for completed cases)
Value to user: Internal teams can compare distributor performance and concentration across club/network channels.

NUMBER OF LENDERS (KPI Card)

What it shows: Distinct lender count in filtered period (with optional blank-lender exclusion). How many lenders are active in this period.
Value to user: Internal teams can monitor marketplace breadth and partner participation.

TOP 5 CONCENTRATION (KPI Card)

What it shows: Sum of case-share percentages for the top 5 lenders by case count volume. How much market control sits with the five biggest lenders. Rank lenders by case count, then add shares for top five.
Value to user: Internal teams can measure concentration risk and diversification health.

BEST COMPLETION RATE (KPI Card)

What it shows: Highest lender completion rate among lenders above minimum volume threshold. Completion rate per lender = completed cases / total lender cases; take max where lender case count is >=100.
Display : KPI subtitle includes the winning rate and the eligibility rule (100+ cases) to make the volume guardrail explicit.
Value to user: Internal users can benchmark what "good" performance looks like.

AVG REVENUE PER LENDER (KPI Card)

What it shows: Typical revenue generated by each lender in this period. Sum valid totalCaseRevenue values across filtered rows and divide by number of active lenders.
Value to user: Internal teams can compare concentration and lender productivity in one KPI strip.

TOP LENDERS BY CASE VOLUME (Chart)

What it shows: Ranked distribution chart of top lenders by case share. Which lenders drive most case volume. Count cases per lender, convert to share of period total, rank top N.
Value to user: Internal teams can identify major contributors and dependency risk.

SWITCHING PATTERNS (Table)

What it shows: Transition counts from prevLender to current lender for changed-lender cases. In plain terms: Where cases move from and to between lenders.
Value to user: Internal users can detect competitive pressure and retention leakage.

CASE MIX BY TOP LENDER (Chart)

What it shows: Stacked case-type composition for leading lenders by case volume. Which lenders are strong in which business types.
Value to user: Internal teams can align partner strategy with segment-specific strength.

ALL LENDERS TABLE (Table)

What it shows: Per-lender metrics: Detailed scorecard to compare lenders on volume, quality, and risk. Colour coded cells show if value is above or below the mean for that metric. LTV values over 1.5 are excluded.
Value to user: Internal teams can identify underperformers and outliers quickly.

Risk and LTV

Internal Dashboard Risk and LTV

AVERAGE LTV (KPI Card)

What it shows: Typical leverage level across current business. Average LTV values where LTV is non-null and within accepted bounds (less than 1.5).
Value to user: Internal teams monitor overall risk appetite in platform flow.

HIGH-LTV CASES (85%+) (KPI Card)

What it shows: Share of cases in higher-risk leverage range. Count high-LTV rows / total valid-LTV rows (less than 1.5).
Value to user: Internal users can quickly track risk pressure in incoming pipeline.

VERY HIGH-LTV CASES (95%+) (KPI Card)

What it shows: Share of cases at very high leverage. Count very-high-LTV rows / total valid-LTV rows (less than 1.5).
Value to user: Internal teams can monitor tail risk and product suitability exposure.

LTV TREND DIRECTION (KPI Card)

What it shows: Difference in average LTV between earlier and later period segments. Whether leverage is trending up or down. Shows the first half of the selected period compared to the second half of the selected period.
Value to user: Internal users can detect drifting risk profile before losses materialize.

LTV DISTRIBUTION (STACKED) (Chart)

What it shows: LTV-band totals plus case-type stacking in each band. Bucket valid LTV rows into configured bands, then split each band by case-type counts (with the final 95%+ band carrying all values above 95% up to the 1.5 LTV cap).
Value to user: Internal teams can connect segment mix to risk concentration.

LTV bands

The LTV band for 95-100% includes all values above 95% up to the 1.5 LTV cap.

AVERAGE LTV BY CASE TYPE (Chart)

What it shows: Mean LTV per normalized case type. Which business segments are riskier on leverage.
Value to user: Internal users can tune segment-specific guidance and partner discussions.

Internal Dashboard Risk and LTV 2

TOP LENDERS BY AVERAGE LTV (Table)

What it shows: Top-volume lenders ranked with avg LTV, high-LTV share (includes LTVs up to 1.5), and high-LTV share delta vs market average. Which major lenders carry higher-leverage books and who over-indexes against market.
Value to user: Internal teams can target risk reviews where exposure is concentrated.

Trends

Internal Dashboard Trends

PERIOD VOLUME (KPI Card)

What it shows: Overall number of cases in scope.
Value to user: Internal teams get baseline scale for all other trend metrics.

AVG WEEKLY VOLUME (KPI Card)

What it shows: Mean case count across weekly buckets. Typical weekly case creation-rate.
Value to user: Internal users can set realistic throughput expectations.

VELOCITY TREND DIRECTION (KPI Card)

What it shows: How completion speed (firstSubmittedDate to completionDate) changed between the first half and second half of the selected period. Difference in average completion days between earlier and later half-period windows. Whether completion speed is improving or slowing.
Value to user: Internal teams can quickly judge directional movement without scanning the full line chart.

AVG COMPLETION VELOCITY (KPI Card)

What it shows: Case-weighted average completion days from submission to completion (firstSubmittedDate to completionDate). Average day difference across all valid submitted+completed rows in the selected period.
Value to user: Internal teams can detect operational drag impacting outcomes.

Average completion velocity vs velocity trend direction

The average completion velocity is the average of the completion days for all valid submitted+completed rows in the full selected period. The velocity trend direction is the difference in average completion days between the first half and second half of the selected period.

PEAK MONTH VOLUME (KPI Card)

What it shows: Maximum monthly case count and month label. Busiest month for case creation in the selected range.
Value to user: Internal users can identify peak load periods for planning.

MONTHLY VOLUME CHART (Chart)

What it shows: The monthly trajectory of demand, with a switch between created and completed case views.
Value to user: Internal teams can validate growth/decline narratives with data.

COMPLETION VELOCITY OVER TIME (Chart)

What it shows: Line chart of monthly average completion days from submission to completion (firstSubmittedDate to completionDate). Whether completion speed is improving or worsening by month.
How it is calculated: Per-month average days from submitted to completed cases.
Value to user: Internal users can measure impact of process improvements over time.

Completion velocity over time drop

Later months have many in-flight cases; only the quickest cases have completed yet, which pulls averages down.

Internal Dashboard Trends 2

NET REVENUE TREND (Chart)

What it shows: How net revenue changes month to month and against normal level. Aggregate monthly netCaseRevenue. Average line = mean monthly total.
Value to user: Internal teams can detect commercial momentum and weak months.

Net revenue trend

Grouping by created month means revenue is attributed to when cases were created, not when commercially realized; later months may include more immature, lower-realized cases.

Data completeness lag (newer months often have less complete financial fields).

CASE MIX SHIFT (Chart)

What it shows: How business composition changed across the year. Sort by createdAt, split rows at the midpoint index, and compare type percentages between first and second halves.
Value to user: Internal teams can separate volume changes from mix-driven changes.

WEEKLY VOLUME TREND TABLE (Table)

What it shows: Last 4 weekly counts, share of period volume, and week-on-week percentage change. Weekly grouping, keep final four weeks in period, share = weekly count / total period volume, and WoW % = (current - previous) / previous with safe null handling.
Value to user: Internal users can spot short-term surges and dips.