Assess a RevOps candidate with a job-related CRM work sample and a discussion of the changes they would propose. Look for accurate policy application, restraint when identity or history is unclear, and a test plan with approvals and recovery limits. This fictional case provides an open dataset and answer key, not a validated hiring cutoff.
Copy CSV text
Select and copy the complete CSV below if the download is unavailable.
contact_id,company_name,lifecycle_stage,lead_status,owner,stage_override_reason,handoff_note,created_date,last_activity_date,previous_owner_confirmed,region_flag C-101,Fictional Co A,Lead,,OWNER-A,,,2026-06-01,2026-06-10,, C-102,Fictional Co B,Marketing Qualified Lead,,OWNER-A,,,2026-05-15,2026-06-02,, C-103,Fictional Co B,Marketing Qualified Lead,,OWNER-A,,,2026-05-15,2026-06-02,, C-104,Fictional Co C,Sales Qualified Lead,New,OWNER-B,,,2026-04-20,2026-06-11,, C-105,Fictional Co D,Sales Qualified Lead,,OWNER-B,,,2026-04-22,2026-06-09,, C-106,Fictional Co E,Customer,Open,OWNER-B,,,2026-01-10,2026-06-01,, C-107,,Marketing Qualified Lead,,OWNER-A,,,2026-06-03,2026-06-08,, C-108,Fictional Co F,Sales Qualified Lead,Open,OWNER-C,,,2026-03-01,2026-06-05,OWNER-B, C-109,Fictional Co G,Marketing Qualified Lead,,OWNER-A,,,2026-05-28,2026-06-07,,outside C-110,Fictional Co C,Marketing Qualified Lead,,OWNER-B,Reverted from Sales Qualified Lead; deal fell through before close; manager approved 2026-06-10,,2026-04-20,2026-06-10,, C-111,Fictional Co H,Opportunity,,OWNER-C,,,2026-06-15,2026-06-12,,
Copy CSV text
Select and copy the complete CSV below if the download is unavailable.
assignment_id,task_name,business_purpose,review_due,owner,access_approver,dataset_state,acceptance_evidence,decision_authority,blocker,next_action ,,,,,,,,,,
Copy CSV text
Select and copy the complete CSV below if the download is unavailable.
assignment_id,task_name,business_purpose,review_due,owner,access_approver,dataset_state,acceptance_evidence,decision_authority,blocker,next_action FCA-FIN-01,Prepare the April reconciliation for two subsidiary accounts,Give the controller a supported explanation of the two subsidiary account balances and a record of unresolved differences after the April ledger close.,"May 8, 2026, 15:00 America/New_York; Reviewer A (controller) reviews the prepared file, unresolved mappings, and access blocker. Example time: replace before assigning. Portal verification and final acceptance remain pending.","Owner A, the new finance hire","Reviewer A, the controller, confirms ERP and shared-drive access and approves read-only bank portal access",April ledger closed as of the 5th; bank statement uploaded to the approved shared drive; the two subsidiary accounts still need confirmed chart-of-accounts mappings,Reconciliation file with source references and explanations for differences; confirmed account mappings; Reviewer A records acceptance after reviewing unresolved items,Reviewer A decides account mappings and treatment of unexplained differences,Bank portal access is pending. Preparation from approved uploaded files can proceed; portal verification remains blocked,Owner A prepares the reconciliation from approved files and flags missing evidence. Reviewer A confirms mappings and resolves portal access before portal verification and final acceptance. FCB-ROPS-01,Review possible duplicate CRM records offline and recommend next steps,Give sales operations an evidence-based recommendation for each flagged pair and identify the ownership decisions needed before considering any separately authorized CRM change.,"September 16, 2026, 14:00 America/New_York; Reviewer B (sales operations lead) reviews the offline recommendations and unresolved ownership questions. Example time: replace before assigning. No live CRM changes are authorized.","Owner B, the new RevOps hire","Reviewer B, the sales operations lead, confirms access to the approved export; no live CRM write or merge access is needed",Monday export for one sales region; an automated rule flagged possible duplicate pairs; none have received human review,"Assessment log covering each flagged pair, the evidence considered, a proposed next step and unresolved questions; Reviewer B reviews and records acceptance",Reviewer B decides how to handle conflicting ownership and whether a separate authorized change should follow,Some pairs have open deals with conflicting ownership and no agreed resolution rule. A final recommendation on those pairs is pending a decision,Owner B records the conflicting evidence and continues reviewing other pairs. Reviewer B resolves the open questions before those recommendations are accepted. No records are merged in this assignment.
A resume tells you what a RevOps candidate has done. It does not tell you how they think when a CRM export is messy, a routing rule has an exception nobody documented, and a sales VP wants to know what changed and why before you touch anything live. This work sample is built to show you that, using a fictional company's data, not your own.
Updated September 15, 2026: this revision keeps the CRM exercise fictional and clarifies the evidence, access boundaries, and handoff responsibilities for a role-specific assessment.
Like our public FP&A practice resource, this exercise gives a hiring manager concrete work to discuss. Here the focus is CRM routing, lifecycle data and change control. It is for US companies hiring a senior RevOps manager, including approximately $10M+ businesses and growth-stage teams. Every record and owner label is fictional. No CRM account, customer data or subscription is needed.
This is a discussion tool, not a validated test. It has not been evaluated against a pool of candidates, and no score is a hiring cutoff. Give each candidate the same data, policy and criteria. Agree on the time budget, compensation, permitted tools and any accommodations before starting. Use the result alongside interviews and references on work they actually owned.
Download the complete 11-record case (CSV), then use the candidate task and row-level answer key.
The fictional company and its routing policy
Fictional Company is an invented mid-market SaaS business. The exported review file uses HubSpot lifecycle labels; it is not a live account export.
HubSpot distinguishes Lifecycle stage from Lead Status. Its default lifecycle options include Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist and Other. Lead Status describes sub-stages within Sales Qualified Lead. Both can be customized. Default automatic stage updates move forward; a manual update can move backward. Some tools require clearing the existing stage before setting an earlier one. Review property history before diagnosing how a change happened. HubSpot's lifecycle documentation explains these differences and subscription limits.
Fictional Company has added its own rules on top of that default behavior. These four rules apply only to this fictional case:
- A contact can move backward in lifecycle stage only if a stage_override_reason is recorded and a manager has approved it. Unapproved backward movement is a defect.
- A contact cannot reach Marketing Qualified Lead without an associated company record. HubSpot does not require this by default; Fictional Company does, because its routing automations key off the company record.
- Every contact at Sales Qualified Lead must have a Lead Status value populated. HubSpot allows Lead Status to sit blank; Fictional Company's sales process does not.
- Reassigning a contact to a new owner requires a completed handoff_note field. This is Fictional Company's own process control, not a CRM requirement.
Fictional Company's policy is silent on two situations: what happens to the Lead Status value after a contact becomes a Customer, and how contacts outside Fictional Company's current sales regions should route. Both come up in the dataset below, and neither has a defined answer. That is deliberate: distinguishing a rule violation from a missing decision is part of what this exercise tests.
The candidate task
Review the complete CSV and four policy rules. The file includes the observed owner-change note for C-108 and the approved stage exception for C-110. There is no hidden evidence to request. Other records have no supplied transition history; a blank reason does not prove a backward change occurred.
- Classify every record as a definite policy defect, a review needed, or no defect established by the supplied evidence. Review includes missing business decisions and unresolved identity or history questions.
- For each definite defect, name the rule and propose the next action. If the replacement value is unknown, say who must establish it. Do not invent a company association, activity, status or handoff note.
- For each review item, identify the missing evidence or decision and its accountable owner. Leave the existing values intact until it is resolved.
- Write a dry-run change ledger with record ID, field, old value, proposed value or pending decision, reason and required approval. Preserve all 11 records. Do not merge or delete anything.
- Write a test plan, a staged rollout proposal and recovery limits. Work offline or in a synthetic sandbox only. Do not import this case into a production CRM.
- Explain the findings and next action to a sales VP in about 150 words, with any agreed accommodations.
Mention reporting impact without inventing a forecast amount. A suspected duplicate or routing gap can affect reporting, but this export has no deal values or identity proof with which to quantify the effect.
The fictional dataset
The CSV contains 11 unique contact IDs. Empty cells mean no value was supplied, except company_name: in this fixture it is the verified associated-company label, and blank explicitly means no company association exists. It is not HubSpot's contact Company name property. Company labels and owner codes are invented. Different contacts can belong to the same company, so matching company names, stages and dates do not establish that two rows describe one person.
The file preserves lifecycle stage, Lead Status, owner, stage exception, handoff note, created date and last activity date. Two extra evidence columns record the supplied owner change and out-of-region flag. These are exercise fields, not a claim about HubSpot's export format.
C-111's activity date precedes its record creation date. That needs source/history review: imported or backfilled activity is one possible explanation. The dates alone do not prove an impossible record or justify overwriting either field.
Row-level answer key
This key is public. For a live selection process, adapt the synthetic values and policy consistently for every candidate, then revalidate the key. Ask candidates to explain their reasoning; recalling these classifications alone is not evidence of judgment.
| Record | Classification | Reasoning and next action |
|---|---|---|
| C-101 | No defect established | Lead with blank Lead Status does not breach the four rules. Preserve the row; no transition history is supplied. |
| C-102 | Review | Possible duplicate with C-103, but shared company and dates are insufficient identity evidence. Request the source identifiers and association history. Keep both records. |
| C-103 | Review | Same unresolved identity question as C-102. Do not choose a survivor or merge based on export order. |
| C-104 | No defect established | SQL with New status satisfies rule 3. No owner change is supplied, so an empty handoff note alone is not a violation. |
| C-105 | Definite policy defect | SQL with blank status violates rule 3. Ask the sales owner to establish the appropriate status from activity evidence. Do not default to New or infer no contact occurred. |
| C-106 | Review | Customer with Open status: the policy does not say whether status should clear after conversion. The lifecycle owner must decide after reviewing reporting and automation dependencies. Preserve Customer. |
| C-107 | Definite policy defect | MQL without an associated company violates rule 2. Hold for identity/association verification by the data owner. Do not invent a company or automatically demote the lifecycle stage. |
| C-108 | Definite policy defect | Supplied history confirms owner changed from OWNER-B to OWNER-C without a handoff note, violating rule 4. Ask those owners for the actual handoff and approval; do not fabricate a note or revert the owner without authorization. |
| C-109 | Review | Out-of-region routing has no stated rule. Sales leadership must define coverage and an accountable owner. Keep the current assignment pending that decision. |
| C-110 | No defect established | The supplied reason and manager approval satisfy the fictional backward-movement exception. Preserve MQL. The note does not establish which HubSpot operation performed the change. |
| C-111 | Review | Earlier activity may reflect import or backfill. Request source timestamps, definitions and property/activity history. Preserve both dates until the discrepancy is explained. |
The 11 records reconcile to three definite policy defects (C-105, C-107, C-108), five review items (C-102, C-103, C-106, C-109, C-111) and three with no defect established (C-101, C-104, C-110). That last category does not certify an entire record or its history as correct.
Test, rollout and recovery
Start with an offline copy or synthetic sandbox. Test valid rows as well as defects, the approved C-110 exception and every unresolved case. A proposed repair must leave unrelated fields unchanged. Run it a second time against the corrected copy: it should propose no further change. Keep the 11 IDs intact throughout this exercise.
For a future production proposal, require the CRM owner to approve explicit values, affected records and dependencies before a small pilot. Observe the pilot's result before expanding. Stop if counts change unexpectedly, protected fields change, an unresolved row is updated, or downstream automation behaves differently from the approved plan. This assessment asks for the proposal; it does not authorize its execution.
Keep field-level old and proposed values, approval and batch version. An export helps reconstruct fields, but cannot undo sent emails, external actions or every consequence of a merge. Do not promise a universal rollback. Identify which effects can be restored and which require a separate recovery process before proposing any production change.
Anchored rubric
Use this to structure a conversation about the candidate's answer, not to produce a numeric score you compare across candidates as a pass or fail line.
Defect versus decision judgment
Strong: separates policy defects from identity, history and business-decision questions; preserves the approved C-110 exception without inventing how it was applied.
Adequate: gets most of the classifications right but treats one or two business-decision records as straightforward defects, or misses that C-110 follows the documented exception.
Weak: treats most ambiguous records as simple defects to fix, or misses several genuine defects entirely.
Policy application precision
Strong: names the specific Fictional Company rule violated for every defect, not a general sense that something looks wrong.
Adequate: identifies the defect but is vague about which rule it breaks.
Weak: flags rows without connecting them to a stated rule.
Test and recovery quality
Strong: tests positive and negative cases, checks a second run makes no further changes, names approvals and stop conditions, and distinguishes reversible fields from irreversible effects.
Adequate: proposes fixes and a rollout, but skips testing or has no rollback path.
Weak: proposes applying fixes directly with no verification or reversal step.
Stakeholder communication
Strong: explains the issue and the fix in plain language a sales VP could act on, in the requested length, with no CRM jargon.
Adequate: is accurate but reads like an internal ticket, not something written for a non-technical reader.
Weak: leaves the sales VP unable to identify the decision or next owner. Evaluate clarity in the agreed format rather than treating length alone as a competence test.
Before the first assignment: separate the hiring test from the hired person's task
Everything above is how you assess someone before you hire them. Once a finance or RevOps hire actually starts, the first real assignment is a different document with a different purpose: a scoped handoff, not another test. Opus publishes a blank first-assignment handoff CSV and fictional examples. The files use nine handoff fields: business purpose, review due date, task owner, access approver, dataset state, acceptance evidence, decision authority, blocker and next action; plus assignment_id and task_name to identify the assignment. The examples use an approved copy or export, not a production change, and the template does not require live CRM or finance-system write access. Use it once someone is hired, after the assessment above has already made the hiring decision.
How this compares to other assessment resources
LatamCent publishes a detailed RevOps interview plan, gated behind an email signup, that includes its own CRM and forecast diagnosis exercise, a rubric, and a weighted scorecard as part of a full six-stage interview process. LatamCent, RevOps manager interview plan This work sample is narrower and open: no email required, one exercise focused on data-quality change control rather than a full interview plan, with an 11-record dataset and a row-level answer key.
Talk through a specific hire
Talk to Opus about your RevOps hire. Bring the systems, responsibilities and reporting expectations for the role.
Related reading
- Assessing a senior FP&A candidate
- Hire a RevOps manager
- Build an internal LATAM recruiting function, or use a partner?
- Which tasks should stay domestic, and which can go to a LATAM hire?
Use consistent job-related questions and rating criteria alongside the exercise, as described in OPM's structured-interview guidance. Its work-sample guidance explains matching tasks to the work and using qualified assessors. Neither source validates this fictional case.
