Estimate infrastructure or support load created by personal finance dashboard

Problem Statement Description

You are evaluating the operational impact of launching or scaling a personal finance dashboard that helps users view accounts, spending, budgets, bills, credit insights, or financial trends in one place. The interview task is to estimate the infrastructure and/or customer support load this product could create, using clear assumptions and a structured guesstimate approach.

Focus on the real usage workflow: users connect financial accounts, sync transactions, refresh balances, categorize spending, receive alerts, and contact support when data looks wrong, connections fail, transactions are missing, or insights feel inaccurate. Your estimate should account for both technical demand, such as data refreshes, API calls, storage, notifications, and compute, and human support demand, such as tickets, chats, escalations, and agent capacity.

You are not expected to know exact industry numbers. The emphasis is on defining scope, choosing reasonable drivers, making assumptions explicit, and showing how changes in adoption, engagement, sync frequency, error rates, and support contact rates affect the final estimate.

The experience should consider:

- The target population and adoption funnel, including registered users, connected-account users, and monthly active users.

- Core usage frequency, such as dashboard visits, account refreshes, transaction imports, alert generation, and report views.

- The unit of infrastructure load being estimated, such as API calls, sync jobs, storage volume, compute events, notification sends, or peak concurrent usage.

- The unit of support load being estimated, such as monthly tickets, chat sessions, calls, escalations, or required support-agent hours.

- Key behavioral assumptions, including number of linked accounts per user, transactions per account, refresh cadence, and percentage of users who encounter issues.

- Segmentation by user type, geography, financial institution reliability, new versus returning users, and power users versus casual users.

- Sensitivity checks for the largest drivers, especially active user count, sync failure rate, support contact rate, and automation/self-serve resolution rate.

- Sanity checks against operational constraints such as agent productivity, response-time expectations, uptime requirements, data privacy sensitivity, and user trust.

The goal is to produce a defensible estimate that helps a product or operations team understand whether the personal finance dashboard can scale reliably, what capacity may be needed, and which assumptions most influence infrastructure cost and support readiness.