← Back to project timeline

Project Detail

Excel Extractor

Employer: Zurich North America Department: Zurich Risk Engineering Engagement: Zurich Risk Engineering Data Engineer Project Type: Reporting automation Visibility: Cross-functional

One-Sentence Summary

Adapted the bulk Excel reporting architecture into an account-level extraction tool that let users compare complex customer histories across more than 20 entities in a single workbook.

The Context

The year was 2006, I was supporting a 500-user workflow system that my team and built the in 2004. This system replace a LotusNotes solution with a client-server solution with a SQL Server backend.

In addition to being a workflow system, the system had a CRM component. What we did not realize during requirements was how often we would have to deal with our customers merging, acquiring, or just going out of business.

When we were dealing with large customers, or customers with years of history, you needed a way to see all aspects of the accounts you are working on.

The Challenge

Provide a way for a user to see everything we know about a specific account in a way that they can compare 2 or more accounts in the same way.

Why It Was Hard

The data for a single customer was spread across more than 20 entities, some of them very wide, and the use case was important but unusual enough that it did not justify adding a comparable feature to the core application. The answer had to be useful, fast to build, and heavily biased toward reuse.

The Constraints

A customer's data is stored in over 20 entities, some of them very wide. Other than a few strange use cases like this, there is no value in trying to build this capability into the system.

The Approach

Reuse the design of our Bulk Excel Workbook Generation as follows:

  • The backend is ready go to, it already handles filtering to a specific customer.
  • The ideas (and much of the code) that went into the Excel solution can be reused here. The only difference is that we are doing multiple entities in the same workbook.

My Role

My intern and I split this solution into two pieces. He owned the Excel side while I owned the back end.

Key Decisions

  • Reuse the backend reporting and Excel-generation patterns from Bulk Excel Workbook Generation instead of creating a new custom extraction stack.
  • Pull multiple entities into the same workbook so users could compare accounts consistently across many aspects of the customer record.

The Outcome

This tool stayed in use for over 10 years with only a few changes. The biggest modification was to extend the filtering to allow for a book of business to be extracted the same way a single customer is extracted. This extended our use cases to include:

  • Marketing and sales
  • Compliance and Legal Hold research
  • Quality and continuous improvement initiatives

Evidence / Signals of Success

  • The tool remained in use for more than 10 years with only a few changes.
  • It expanded from single-account extraction to book-of-business extraction.
  • The resulting use cases grew to include marketing and sales, compliance and legal hold research, and quality and continuous improvement work.

Resume Bullet Seeds

  • Reused an existing reporting architecture to build an Excel-based account extractor that assembled customer history across 20-plus entities into a single comparison workbook.
  • Delivered a targeted analytical tool that stayed in use for more than a decade and later expanded from individual-account research to book-of-business analysis.

Interview Story Angles

  • Reusing a proven architecture to solve a new but related problem quickly.
  • Choosing a focused auxiliary tool instead of forcing uncommon functionality into the core application.
  • Handling mergers, acquisitions, and customer-history complexity in operational systems.
  • Splitting backend and Excel responsibilities across team members.

Lessons Learned

  • Mergers, Acquisitions, and Going Out-of-Business Happen
  • Temporary Solutions Are Not Always Temporary