Skip to content

Custom development

An order book on a map, and the customer who was a fifth of it

Every order had an address and none had coordinates. Once they were mapped, one account turned out to be 20% of the book and the default view was hiding another 35%.

Built for
SMT Research, Vancouver
Service line
Custom development
Window
Jun to Sep 2026
The headline number100%Of the order book placed on a mapFrom a starting point of zero. The book was recorded at 254 orders carrying an address and the geocoding run at 252 of 252. We have not reconciled the gap.

01Key numbers

What we measured

252 / 252Order addresses geocodedAccuracy split: 177 to the address, 48 to the block, 15 to the city, 12 to the street.
252Of contract value placed on the mapContract value excluding tax, not currency converted. 234 orders in Canada, 13 in the US, 5 elsewhere.
20.1%Of the order book sat with one account51 of 254 orders. Measured by order count, not by dollar value.
74 / 74Apex tests passing at handoverCoverage from 89% to 100% across nine classes.

02The situation

What was true before

The firm had 254 orders carrying a shipping address. None of them had coordinates, so nothing was on a map and no territory review was possible without asking someone to build a report.

Customer concentration risk was therefore invisible. Not disputed, not estimated, simply not visible to anyone.

Contact us to find out more

Recognise this in your own org?

03What we built

The mechanism

A Lightning Web Component over a map, with geocoding and model work moved off the request path and onto a schedule.

One geocoding service called three ways

New orders geocode on save through a trigger, the back catalogue geocodes in batch, and a nightly queueable chain fills the gaps. A wrong location is worse than an empty one, so there is no any-province-to-its-country guess.

Three keys, three different stores, one stated reason

The browser Maps key sits in a custom setting, the server geocoding key in config, and the model key in a named credential password. In an unmanaged org, protected visibility on a custom setting restricts only managed-package subscribers, so it is not access control there.

Designed around a 120-second callout budget

Apex allows 120 seconds of cumulative callout time per transaction. The chain takes four orders per execution with 25, 45 and 60 second timeouts and a 90-second wall-clock stop. It is built never to reach the limit rather than to recover from hitting it.

Model generation moved off platform after it failed in production

The first full run analysed 2 of 256 orders and stamped 250 with a rate-limit error, because the free tier caps the model at 20 requests per project per day. Generation moved to a hosted worker. Prompts, inputs and the cache rule stayed in Apex so the two paths cannot drift.

Sales and Forecasting
252 orders · 100% geocoded
Concentration
Largest customer20.1%
51 of 254 orders
Next four combined21.7%
55 orders
Everyone else58.2%
148 orders

Percentages are of order count, not value. The book carries two currencies as entered and is not converted.

Depiction · Every won order geocoded and plotted, coloured by status. 252 of 252 orders placed, from a starting point of zero with coordinates.The largest circle is one customer. It turned out to be a fifth of the entire book, which nobody knew until the map existed. That finding was worth more than the map.

Surfaces built

We will demonstrate any of these live, on the real org,.

  • Order map with concentration shadingImage withheld
  • Order card with open tasks and written next actionsImage withheld
  • Nightly portfolio insight panel, model output as plain textImage withheld
The finding

The default view was hiding 35% of the book.

89 of 254 orders sat in statuses that the default filter excluded. Nobody had chosen to hide them. Finding that was worth more than the map itself, because the map was only the instrument that made it visible.

04Outcome

What changed, verified

The map shipped with geocoding complete, insight generation running nightly, and an alert that fires when it stops.

  • One account confirmed at 51 of 254 orders, 20.1% of the book by count.
  • 152 open tasks surfaced directly on the order cards rather than in a separate report.
  • A full model rebuild across all 254 orders costs a dollar or two and runs in 10 to 20 minutes.
  • A hosted worker polls every five minutes and an hourly watchdog emails if it misses a 60-minute check-in.
How it was verified

An adversarial review produced 30 finding reports, de-duplicated to 16 distinct defects. Fifteen were fixed, one partially, and 14 further findings were investigated and rejected.

Sources
  • docs/research/02-revenue-systems.md §1 · Sales Map
  • docs/research/02-revenue-systems.md §1 · The platform-limit story
  • docs/research/03-ai-systems.md §4 · The Apex-to-worker migration

Keep reading

Two more

All case studies
  • Custom development
    31%Of quote lines carried no tax code5,997 of 19,255 lines. 5,182 of them sit on Canadian job sites.

    A tax engine rebuilt from 28 rows of configuration

    The client told us the tax was calculating by product instead of by province. We tested that against all 2,335 order line items and it was not true. Six other defects were, and we priced each one.

  • Custom development
    5 to 6Systems a field technician checked each morningThe recorded before state. No after count was measured, so we do not publish one.

    Five to six systems every morning, and a flow that logged nothing

    Field crews were opening five or six systems before starting work, and a logging flow was telling them it had saved data when it had saved nothing.

Next step

Bring us your hardest Salesforce problem

Tell us what is broken. You get a written read on it within one business day, before any money changes hands.

  • Reply within one business day
  • Live walkthrough of the org itself
  • Vancouver, British Columbia