Business Analyst Case Study Interview Questions & Answers (2026)

I'd start by mapping the current process end-to-end: order receipt → validation → inventory check → payment processing → fulfillment → shipping. For each step, I'd measure: time elapsed, who performs it, what systems are involved, and what causes delays. I'd ask: where does the order physically wait the longest? Common findings in order processing: manual data entry from emails/faxes to the order system (1 day), batch inventory checks running once daily (1 day), manual credit approval for orders over a threshold (1 day), fulfillment queue processing (1 day), shipping label generation and carrier scheduling (1 day). For each bottleneck, I'd propose solutions: replace manual data entry with automated order import (API integration or OCR for paper orders). Replace daily batch inventory checks with real-time inventory API queries. Implement rules-based auto-approval for credit checks below a threshold (auto-approve orders under $5K from customers with good history). Enable real-time fulfillment assignment with pick-pack-ship workflow. Integrate carrier API for instant shipping label generation. Prioritization: I'd rank by impact (time saved) × feasibility (implementation complexity). The highest-impact, lowest-effort changes first: real-time inventory checks and auto-approval rules could cut 2 days immediately with modest IT investment. Full automation of order entry requires more integration work but eliminates another day. Target: achieve the 1-day goal through a phased approach over 2-3 months.

I'd start by analyzing current support tickets to understand what a self-service portal can realistically deflect. I'd categorize tickets by type: password resets, order status queries, billing questions, return/refund requests, product questions, and complex technical issues. The first four categories are typically 60-70% of tickets and are self-service candidates. Complex issues require human agents. Personas: frequent buyers who want quick answers, new customers unfamiliar with the product, and frustrated customers with billing issues. Each has different self-service needs. Priority 1 requirements (core): searchable knowledge base with top 50 FAQs, account dashboard showing order status and tracking, password reset and account management, and billing history with invoice download. Priority 2 requirements (deflection multipliers): AI-powered chatbot for guided troubleshooting, community forum where customers help each other, video tutorials for common product setup issues. Priority 3 requirements (optimization): predictive search suggesting solutions as users type, ticket deflection tracking (show solutions before allowing ticket creation), and user satisfaction rating for self-service articles. Acceptance criteria for the 40% target: each feature should have a measurable deflection rate. Knowledge base alone typically deflects 20-25% of tickets. Account dashboard adds 10-15%. Chatbot adds 5-10%. Non-functional requirements: mobile-responsive, <2 second page load, accessible (WCAG 2.1 AA), and SSO integration.

When stakeholders say a system is 'broken,' they usually mean it doesn't support their workflow, not that it's technically non-functional. I'd investigate through three channels. User interviews: talk to 5-8 sales reps across experience levels and deal sizes. Ask: 'Walk me through how you use the CRM in a typical day. Where do you get frustrated?' I'm looking for specific pain points, not general complaints. Data analysis: pull CRM usage metrics — how many fields are actually populated, what's the data entry completion rate, how often do users log in, and where do they spend time. Low adoption signals a workflow mismatch. Process observation: shadow 2-3 sales reps for a half day each. Watch them work. The gap between what they say and what they do reveals the real problems. Likely findings: too many required fields that don't add value (they enter garbage to proceed), the mobile experience is poor (sales reps are often on the road), pipeline stages don't match the actual sales process, and the CRM doesn't integrate with the email and calendar tools they actually use. I'd document findings as specific problem statements: 'Sales reps spend 45 minutes/day on CRM data entry that doesn't help them close deals' is actionable. 'The CRM is broken' is not. I'd present findings to both sales leadership and IT with prioritized recommendations, estimated impact on sales productivity, and a definition of 'fixed' that both teams agree on.

This is as much a change management challenge as a technology selection challenge. I'd approach it in phases. Phase 1 — Current state analysis: inventory all spreadsheets used for project tracking. Who uses them, for what purpose, and what data do they contain? Identify the implicit workflow: are spreadsheets emailed around, shared on a drive, or edited collaboratively? What works well that we need to preserve? What's painful? Phase 2 — Requirements: based on the analysis, define must-haves (task assignment, status tracking, deadline management, reporting), nice-to-haves (time tracking, resource management, Gantt charts), and deal-breakers (must integrate with existing tools like Slack, email). Critically: talk to both power users (who've built complex spreadsheets) and light users (who just need to see their tasks). Phase 3 — Tool evaluation: evaluate 3-4 tools (Jira, Asana, Monday, Smartsheet) against requirements with a weighted scoring matrix. Include cost, learning curve, and migration effort. Run a 2-week pilot with 1-2 teams. Phase 4 — Migration plan: migrate historical data where valuable (active projects yes, completed projects only if needed for reporting). Create templates that mirror the familiar spreadsheet structure initially — then evolve. Phase 5 — Change management: training sessions, a champion network (1-2 advocates per team), 30-60-90 day check-ins, and a clear communication that explains why the change benefits them personally (not just the company). Success metrics: tool adoption rate (>80% within 90 days), project visibility improvement, and reduction in 'status update' meetings.

I'd structure this as a comparative analysis across five dimensions. Requirements definition: what does the company need from a CDP? Customer identity resolution across channels, unified customer profile, segmentation for marketing, real-time data ingestion, and integration with existing martech stack. Build analysis: engineering team estimates 6-month build with 4 engineers ($600K fully loaded). Ongoing maintenance: 1.5 FTE ($225K/year). Infrastructure costs: $3K/month ($36K/year). 3-year TCO: $600K + $36K + ($225K × 3) + ($36K × 3) = $1.4M. Plus opportunity cost: those 4 engineers aren't building product features for 6 months. Buy analysis: vendor CDP (Segment, mParticle, Tealium): $50K-$200K/year depending on data volume. Integration effort: 2 engineers for 2 months ($100K). 3-year TCO: $100K + ($150K × 3) = $550K. Faster time to value: operational in 2 months vs 6 months. Strategic factors: Build if the CDP is a core competitive advantage (rare), if data privacy requirements make third-party processing unacceptable, or if existing vendors don't meet unique requirements. Buy if time-to-value matters, if the company's core competency isn't data infrastructure, or if the vendor provides features beyond what you'd build (identity resolution algorithms, pre-built integrations). My recommendation: buy, unless there's a specific requirement that no vendor can meet. The TCO is lower, time-to-value is faster, and engineering resources should focus on the company's core product differentiation.