Design a centralized participant management system to prevent over-contacting

WHAT THIS TESTS: ResearchOps systems design and governance at enterprise scale. The interviewer wants to see if you can move beyond ad-hoc recruiting to build infrastructure that preserves participant trust, prevents survey fatigue, and maintains data quality across dozens of product teams. They are looking for awareness of the tension between research velocity and panel health, plus the ability to translate policy into enforceable system rules.

A GOOD ANSWER COVERS: First, a unified data model. The system must store contact history with timestamps and channel, study participation outcomes such as completed, no-show, or screened out, consent and communication preferences, demographic and segment tags, and a computed fatigue or recency score. Second, hard governance rules rather than best-effort guidelines. Examples include a maximum of one outreach per 30 days, a 90-day cooling-off period after any completed study, and an automatic block on anyone who has opted out or hit their annual participation cap. Third, system architecture for cross-team visibility. A centralized registry should expose a shared queue or API so teams can see pending and past studies for any participant before initiating contact. Fourth, bias mitigation. The answer should address capping power-user or brand-loyal participants at roughly 20 percent of total studies, tracking new-user versus existing-user ratios, and supplementing the internal panel with external recruiting to avoid echo chambers. Fifth, privacy and compliance. The design must include GDPR or CCPA deletion workflows, explicit consent records, and role-based access controls.

COMMON WRONG ANSWERS: Proposing that each team maintains its own spreadsheet and simply checks a shared calendar. Suggesting soft rules like please do not email too often without system enforcement. Tracking only email sends rather than actual study participation, which leads to undercounting real burden on participants. Ignoring opt-out mechanics or assuming marketing unsubscribe lists are sufficient. Failing to account for sampling bias, which NN Group notes is a major risk of internal panels because participants develop brand loyalty and may provide artificially positive feedback.

LIKELY FOLLOW-UPS: How would you handle a high-priority study that needs to reach the exact segment currently in a cooling-off period? How do you balance the cost of building this system versus continuing to pay external recruiters? What metrics would you use to prove the panel is healthy and not burned out? How would you integrate this with existing CRM or data warehouses?

ONE CONCRETE EXAMPLE: Imagine a SaaS company with 15 product teams. A researcher wants to recruit enterprise admins who have not been contacted in 60 days. The system returns a pool of 40 eligible admins but flags that 12 are already scheduled for other studies next week. The researcher submits a request that enters a shared queue. The system auto-enforces the 30-day contact rule and the 90-day post-study cooling-off. It also flags that enterprise admins have already represented 40 percent of this quarter's studies, triggering a bias alert that prompts the team to source external participants to balance the sample.

Source: nngroup.com