A sales forecast that updates with every CRM change, territory assignment across ~200k accounts, trade show lead routing, and map-based outbound prospecting. Built mostly in Salesforce, Apex, and Python.
Production work and proofs of concept, anonymized for publication.
Proof-of-concept that gives every CRM update the benefit of a detailed account analysis for a fraction of a cent. Each case, email, and invoice re-scores the forecast for the product line it concerns, with the reason logged.
Salesforce-native rep routing for ~200k accounts across eight product lines and 7 divisions at a multi-division distributor. Geographic lookup, selling rep derivation, and access control through Enterprise Territory Management.
A native processing engine that uses generative AI and multi-factor fuzzy matching to parse, enrich, and route bulk-imported trade show scans into timely follow-ups.
Proof-of-concept outbound system that generates hyper-localized prospecting emails for a B2B manufacturer. Each email embeds a custom map of unfilled commercial demand within 10 miles of the prospect's HQ.
I design and build the systems that modern sales organizations run on. From complex territory models and programmatic lead routing to advanced CRM architecture and data pipelines, my work bridges the gap between overarching strategy and flawless technical execution.
I approach revenue operations with a developer's mindset. I believe that internal GTM infrastructure deserves the same technical rigor and scalability that you would apply to core product engineering.
Salesforce (Apex, LWC, Flows, SOQL), Enterprise Territory Management, Revenue Cloud, CRM Analytics
Claude Code, spec-driven development, Salesforce MCP, LLM APIs, Agentforce, n8n, Zapier, Temporal
Python, SQL, geocoding, spatial analysis, fuzzy matching and deduplication, Qlik
Clay, lead enrichment and routing, territory and account segmentation, outbound pipelines
Interested in working together or have a question about one of my projects? Send me a message and I'll get back to you.
Salesforce-native rep routing for ~200k accounts across eight product lines and 7 divisions at a multi-division distributor.
The company needed to recreate and fortify its assignment logic coming out of a legacy CRM into a shared Salesforce organization. At any given time, only one sales team could sell a given product to a customer. In the legacy CRM, this information was often inaccurate, leading to underserved accounts.
The system looks up a customer's zip, stamps the right rep per division, applies business rules to resolve ties and special cases, then grants those reps access to the account through Salesforce's native sharing model.
A custom object maps each U.S. zip code to per-division territory rep initials. This is the workaround for the ETM platform limit. Rules are capped at 1,048 characters, which made rule-based ETM unworkable for a nationwide footprint. The zip lookup sidesteps that entirely.
A before-insert/before-update trigger reads the zip lookup and stamps eight geo rep fields on the Account.
A service class computes the actual assigned rep per product line from the geo reps, the account's assignment type, the account type, and related records created by the ERP that override the default. Each product has its own derivation rule; the shared product lines swap main and alternate reps based on assignment states that are calculated interdependently.
An async queueable diffs the desired territory set against existing ObjectTerritory2Association records and creates or deletes as needed. ETM then provides record-level sharing to the assigned reps.
When a zip's geo rep changes (territory redraw), the trigger re-derives selling reps for affected accounts. But selling reps can have manual exceptions; an account isn't necessarily assigned to the geographic default. Running broad derivation would wipe those exceptions.
Solution: Snapshot all selling rep fields before derivation, run derivation, then restore any field that had a non-blank value pre-derivation. Exceptions preserved, blanks filled in. Single-pass, bulk-safe, no metadata tracking required.
The system is designed to fail safely, log its own problems, and stay fast at bulk-import scale. Every piece can be shut off independently without taking the rest down. Two hierarchy-level custom settings control execution:
Every public entry point on the trigger handler checks the relevant switch before doing anything. An integration user can be granted bypass without affecting interactive users.
Instead of failing silently or throwing, the ETM queueable logs a typed record to a dedicated error object: unmatched territory names, query failures, insert failures, delete failures. Territory managers get a queryable backlog of data issues rather than an opaque failure with no starting point.
A Lightning component displays selling reps and geo reps as two toggleable views on the account page. Edit mode is gated by server-side authorization: the running user must either hold a permission set or have initials matching the displayed rep fields.
What used to take days of back-and-forth and an unknown turnaround now takes an internal pull request. Sales has visibility and clarity they didn't have before. Data quality issues get surfaced rather than hidden.
Territory managers now have a queryable backlog of assignment issues instead of opaque failures. Reps see their own assignments on the account page and can self-correct through governed edit controls. Engineering can ship logic changes in hours through a change set.
| Layer | Technology |
|---|---|
| Platform | Salesforce with Enterprise Territory Management |
| Backend | Apex |
| Frontend | Lightning Web Component |
A native processing engine that uses generative AI and multi-factor fuzzy matching to parse, enrich, and route bulk-imported trade show scans into timely follow-ups.
Reps capture hundreds of badge scans at trade shows, dictating unstructured notes into a mobile app. Scans are exported to CSV and bulk-imported into Salesforce for follow-up the Monday after the show. Sorting which scans matched existing accounts vs. net-new prospects used to take weeks.
The system intercepts the import and combines the Gemini API with on-platform Salesforce logic to structure and route leads before Monday outreach.
An async Apex batch handles the bulk import without hitting concurrent governor limits.
Apex passes each dictated note to Gemini with a prompt that forces a structured JSON response: the competitor mentioned and a standardized product category. An injected synonym map keeps messy field notes strictly bound to internal categories.
Apex cross-references each scan against existing Contacts and Accounts on email, phone, and address, with a fuzzy match on company name to link the scan to the right CRM record.
The enriched payload hands off to a Salesforce Flow that executes the Monday follow-up logic based on the match results.
On a match, the interaction is linked to the Account and a targeted Task is generated for the rep(s) covering the relevant categories, surfacing the standardized product interest and competitor intel.
If no match is found, a new Lead is created with category and competitor mapped to custom fields and routed to the relevant rep(s) for qualification.
Post-show CSV dumps become prioritized action items. Reps start Monday with targeted tasks on the right accounts and enriched net-new leads pre-categorized by product interest. No high-intent interaction gets lost in manual sorting.
A proof-of-concept outbound sales system that generates hyper-localized prospecting emails for a B2B manufacturer. Each email embeds a custom map showing unfilled commercial demand within a 10-mile radius of the prospect's HQ.
The target persona is a regional service contractor who could become a certified installation partner. The email doesn't sell directly; it sells the demand signal the prospect didn't know existed in their area. Every red dot on the embedded map represents a real commercial site that requires installation services, and the contractor's office is pinned at the center.
Example email: personalized map showing unfilled commercial demand near a prospect's HQ in the DFW metroplex.
| Layer | Tool |
|---|---|
| Public registry scraping | Python |
| Geocoding | Google Maps API / Census TIGER |
| Spatial matching | geopy |
| Map rendering | OpenStreetMap tiles with CSS overlay |
| Email templating | Jinja2, inline CSS |
Public infrastructure registries and municipal databases are scraped and normalized into a table of commercial sites with lat/lon and installation status. For each prospect, a spatial query pulls all active sites within 10 miles that have no assigned service partner.
The map is rendered as a CSS grid of real OpenStreetMap tile images. Each map is a self-contained static image that can be rasterized to PNG or embedded inline in an email.
Pattern interrupt: A personalized map in a cold email is visually jarring. The prospect sees their own city, their own neighborhood, their own HQ pinned on a map surrounded by red dots. That's hard to ignore.
Data-backed urgency: Every dot represents real commercial demand. The email doesn't make vague claims about "market opportunity"; it shows specific, verifiable demand in the prospect's backyard.
Scalable personalization: The pipeline generates a unique map for every prospect. The marginal cost of personalizing the 1,000th email is the same as the 1st.
Open rate lift: Personalized content consistently outperforms generic copy by 2-3x in B2B outbound benchmarks.
Pipeline coverage: A single engineer automates the research that would take each sales rep weeks to do throughout their territory.
A Salesforce proof of concept that gives every record update the benefit of a detailed account-level analysis for a fraction of a cent, using TypeSafe's Jev model.
The most useful forecast input is someone actually reading the account: its open cases, its latest emails, its order history, and what they mean together. That takes a person's time, so it happens occasionally, and the forecast drifts in between.
The goal was to run that review every time a case, email, opportunity, or invoice changes. Jev scores the record in the context of its account, the result lands on the product line it concerns, and every movement is logged with its reason and the record that caused it.
Product lines matter because wholesale accounts rarely buy on one rhythm. A clothing retailer might reorder socks monthly and jackets once a year. An account-level average blends those into an order interval that describes no real behavior, and a complaint about one line writes down the whole account.
An angry case about pulled seams on cashmere shirts, scored live. Escalation probability cleared the confidence gate, so the status moved to Escalated and the change was logged.
The same account's product lines afterward. Only Luxury Shirts moved, and the task engine created two follow-ups on the account.
Ordinary record changes drive everything. A record-triggered Flow routes each event to an invocable Apex action, which asks Jev structured questions about the record and its account context. Jev's answers land in raw fields, and Salesforce formulas turn them into the forecast.
A custom object holds one row per account per product line, each with its own invoice stats, order pattern (Program, Repeat, One-time, or Dormant), cadence, reorder probability, and 90-day forecast. The account forecast is the sum of its rows plus open opportunities.
Seven record-triggered Flows cover cases, case comments, sales activity, opportunities, invoices, and leads. Apex calls Jev from a queueable chain with retry and backoff, and a nightly job re-asks any product line that has gone overdue.
Jev's answers are written only to raw and choice fields. Every calibrated number is a formula over those fields and a custom setting of weights and thresholds, so changing one weight reprices every record instantly with no new model calls.
Every field that moves writes one ledger row: the reason, the previous and new value, the triggering record, the model's confidence, and version stamps for both the config and the question set.
Tasks come only from a central engine, fired by ledger changes and a nightly sweep. Each of its 19 signals is a class registered by one custom metadata row, deduped per account and product line, and reportable by trigger.
A case that names a product resolves to its product line through the product family, and its drag applies only to that row. A case naming no product, or one with a company-level root cause, applies across every line.
In the demo, an angry quality complaint lowered the Luxury Shirts forecast, and the account total fell by exactly that row's drop. The other four lines did not move.
Not every update needs a model. Invoice activation recomputes a line's stats, pattern, and forecast in Apex: three invoices of one type flip its pattern and raise its forecast with zero callouts and zero async jobs.
A two-tier regularity test keeps pattern detection honest at low invoice counts. It uses interval spread at two intervals and coefficient of variation at three or more.
Jev can suggest a new case status or opportunity stage. The suggestion applies automatically only above an 85% confidence gate and is always logged. One setting turns auto-apply off in favor of a rep task, and closed opportunities are never rewritten.
The whole org rebuilds from source plus one idempotent seed: 40 SKUs, 20 retailers, and 18 months of per-line invoice history across 796 orders. Seeded records never trigger automation. 444 Apex tests pass at 94% org-wide coverage.
Could a cheaper Salesforce-hosted model do the same job? Seven scoring requests built from live demo data went to Jev and to five models on Agentforce's model gateway, three runs each, for 126 calls in total. The general-purpose models received the same JSON plus instructions asking for Jev's answer shape and telling them to weigh facts over free-text claims.
| Model | Tier | Matched Jev | Repeatable | Flagged Angry Case | Shift from Injected Claim |
|---|---|---|---|---|---|
| Jev | — | — | 100% | 100% | +9 pts |
| Claude Haiku 4.5 | Basic | 100% | 82% | 100% | +46 pts |
| GPT-4.1 mini | Basic | 88% | 71% | 100% | +5 pts |
| Gemini 2.5 Flash | Basic | 83% | 71% | 0% | +88 pts |
| GPT-4o mini | Basic | 79% | 76% | 0% | +3 pts |
| GPT-4.1 | Standard | 71% | 71% | 100% | +58 pts |
Two cheap models fail the demo: GPT-4o mini and Gemini 2.5 Flash rated a third-shipment quality complaint as merely frustrated, below the escalation threshold, so the escalation task would never fire.
Resistance to claims: Injecting "We will definitely reorder socks next week, guaranteed" moved Gemini from 2% to 90%. Jev moved 9 points, by the same amount on every run, because its instructions weight invoices above stated intent.
Stability: Jev's answers moved at most 3 points across identical runs and came back in about 0.1 seconds per call, against 1.1 to 1.9 seconds for the hosted models.
An open question: One account had ordered socks every month for a year and missed a single order. Jev put the chance of a reorder at 53%. Every other model said 2 to 15%, apparently anchoring on the "Dormant" label. Only real outcomes can settle which is right.
Cost: The demo's four calls used about 4,000 Jev tokens, roughly $0.0002. On Agentforce's Basic tier, the same four calls cost about $0.04 in Flex Credits, and as four agent actions they would cost $0.40 before model credits.
Every pass criterion was observed on a live org with Jev answering real API calls. Product-scoped cases moved only their line, account-level cases moved every line, invoices updated patterns without a model call, and one config change repriced every row with no rescore.
The POC proves the mechanism, not the accuracy. Seed data is synthetic and there is no backtest, so the next step is running the model against real customer history.
| Layer | Technology |
|---|---|
| Platform | Salesforce DX, Enterprise scratch orgs |
| Automation | Record-triggered Flows, invocable, queueable, and schedulable Apex |
| Model | Jev by TypeSafe, via Named Credential |
| Configuration | Hierarchy custom setting, custom metadata |
| Reporting | Salesforce reports and dashboard |
| Evaluation | Agentforce Models API |