Build an inbound lead audit for your GTM engineering portfolio

An inbound lead audit makes a useful GTM engineering portfolio project because the question is concrete: did a request reach the right team, and did someone address it? You can demonstrate data modeling, workflow diagnosis and measurement without buying a sales stack or sending anyone an email.

Start with our 16-row synthetic event file and exercise rules. Use a spreadsheet, SQL, Python or a workflow tool you already know. There is an answer key for checking your work. All records and outcomes are fictional; the project needs no CRM credentials, paid enrichment or model API.

The deliverable is a short audit, one demonstrated repair and a handoff another operator can follow. A screenshot of a workflow is useful supporting material. The decisions and evidence are the project.

Why this resembles actual GTM work

Grow Therapy’s GTM Engineer posting includes intake validation, routing, data models, testing and monitoring. LangChain’s Software Engineer, Agent Systems posting includes production monitoring, recurring evaluations, regression tests and business metrics. We checked both employer sources on October 22, 2026.

Those are examples of responsibilities this exercise can help you discuss. They do not mean these employers use this assignment or that completing it qualifies you for either role. For a broader comparison, read our guide to GTM engineer skills.

1. Decide what should happen before looking at what did

The fixture describes a fictional company serving new demo requests from the US and Canada. Existing customers go to customer success. Some requests need review, some are outside its market, and some must be suppressed under the exercise’s contact policy.

Apply these rules in order:

Order	Condition	Expected decision
1	The event_id appeared earlier in the file	Ignore the replay; do not count or act again.
2	opted_out is true	Suppress automated contact in this exercise.
3	contact_valid is false	Manual review.
4	existing_customer is true	Route to customer_success.
5	Country is missing	Manual review.
6	Country is outside US and CA	Mark out of scope.
7	Request type is not demo	Manual review.
8	Otherwise	Route US to us_sales and CA to canada_sales.

These are declared test rules, including the suppression rule for existing customers. A real business would need its own rules for support and contact permissions. Do not quietly replace the exercise policy with an assumption about how your last company worked.

Create an output with row_id, expected_action, expected_owner and reason. Keep the original event file unchanged. A blank expected owner for a review or suppressed record means this workflow should not assign it to sales or customer success; your design still needs a person or team responsible for the review queue.

2. Keep the clocks separate

The file includes five timestamps:

• received_at: the form event arrived.
• crm_created_at: a CRM record was created.
• owner_assigned_at: a team was assigned.
• acknowledged_at: an automatic receipt was sent.
• useful_response_at: a response addressed the request and provided a next step.

The fixture supplies the last classification. In a real audit you would inspect messages to establish it. An automatic receipt does not prove that a request reached the right team or received a useful answer.

Use received_at as the start of response time. Starting at CRM creation makes capture delays disappear. The snapshot is October 21, 2026 at 12:00 UTC, and every event is older than the exercise’s 30 elapsed minute target. Off-hours count. That target is a test assumption, not a recommended service level for every business.

3. Find the failure, then locate its owner

Try the audit before opening the answer key. A few cases show why the distinction between an expected action and a completed action matters:

Case	What the observations show	What to investigate
R02	The same event as R01 appears twice.	Does replaying an event create another task or inflate the report?
R05	A request with no country was assigned to US sales.	Which rule substituted a guess for missing information?
R08	An eligible US demo request has a CRM write error.	Where is the failure recorded, and who owns recovery?
R09	A Canadian demo request reached US sales.	Is the territory mapping wrong, or did a later step overwrite the owner?
R10	The right owner and an automatic receipt exist, but no useful response does.	Who owns follow-up after routing succeeds?
R16	An eligible request never reached the CRM.	Can the audit see intake events independently of CRM records?

The file tells you what happened, not every cause. “The country mapping is wrong” is a hypothesis until you inspect the rule or trace. That distinction belongs in the audit.

4. Report the denominator, including unfinished work

For this exercise, response metrics cover unique events that should route, even if the CRM write failed. Include the customer-success route and disclose it separately from sales. Exclude replays, suppressed records, out-of-scope requests and manual-review cases from that specific denominator; report their counts alongside it.

The answer-key totals are:

Measure	Synthetic result
Observed rows / unique events	16 / 15
Expected routes	9: eight sales, one customer success
Other unique decisions	Three manual reviews, two suppressed, one out of scope
Correct observed owner	6 of 9 expected routes
Useful response within 30 elapsed minutes	4 of 9 expected routes
Still without a useful response at the snapshot	4 of 9 expected routes
Median among the five responded routes	12 minutes
Nearest-rank p90 among those five responses	60 minutes

The responded durations are 4, 8, 12, 20 and 60 minutes. For nearest-rank p90, sort the values and take position ceiling(0.9 × count), starting at position one. Here that is the fifth value. Other percentile methods can differ on such a small sample; name yours.

The 12-minute median leaves four unanswered requests out of its calculation. Reporting only that number would hide the unfinished work. Equally, nine expected routes are not nine qualified opportunities. The dataset has no meetings, accepted opportunities, closed deals or revenue outcomes.

5. Repair one path and show the replay

Choose a bounded change: fix the country mapping, preserve a failed CRM write for recovery, or prevent an event replay from creating another action. Record the proposed repair separately from the original observations.

Show a normal case, the failure case and a repeated event. Explain the expected number of resulting assignments or tasks. Re-running an integration should not accidentally duplicate its business action. If a write times out, explain how you would determine whether it succeeded before retrying it.

For an n8n implementation, its error-workflow documentation describes routing execution failures into a workflow that starts with an Error Trigger. That can make a failure visible. You still need to design recovery and check whether the business action happened.

AI is optional here. The supplied routing rules are deterministic. An extension could classify free-text requests or draft a response, but keep that experiment separate: supply labeled examples, inspect errors and preserve the contact rules. Adding a model call does not establish that the process improved.

Package it for a portfolio conversation

Submit the original fixture, your decision output, the calculation method and one before-and-after trace. Add a short note covering the user of the system, the failure you chose to fix, why it mattered, and what remains unresolved.

A precise portfolio statement is: “I audited 15 unique synthetic events, found four eligible requests without a useful response, and demonstrated a repair to one routing failure.” Only claim the repair if you ran it. Keep any simulated response times labeled as simulated; the answer key is not evidence of revenue saved.

Compare the work with current GTM engineering jobs, marketing operations jobs and RevOps jobs. Choose the role whose responsibilities match the part of the system you want to own.