I came in as an outside advisor. I left running a 26-country region.

I came into this engagement as an outside advisor through my own consulting firm. I left eleven years later as the Business Relationship Manager for a twenty-six-country region, having built two platforms the business ran on and having entered the Salesforce ecosystem through the side door.

The client was a $2.8 billion equipment finance operation doing business worldwide. I owned EAME, twenty-six countries across Europe, Africa, and the Middle East. Two colleagues carried the other regions. All three of us worked from the United States.

It is a long engagement, so here it is in order.

The platform the business ran on

When I arrived, the commercial side was running on ACT!, a contact manager doing a job well outside what a contact manager is for.

I replaced it with an origination platform I designed and built. Loan applications went into it. Credit decisioning ran through it. Title work lived in it. Contract lifecycle management, reporting, and the daily operational record all moved into the same system. It stopped being a system alongside the work and became the place the work happened.

I built it and I maintained it, and it carried production volume for most of a decade.

That is an unusual thing to be able to say, and it shaped everything after. When you own the system the business runs on, you learn the business the way the people operating it do. You find out which credit exception keeps recurring, which title step always stalls, which report somebody rebuilds by hand every month because the system never gave them the cut they needed. None of that arrives in a requirements document. It arrives because you are the one who gets called.

Turning public records into a pipeline

The second platform mattered more commercially, and it started from an observation about public data.

In equipment finance, when a lender takes a security interest in a machine, it gets recorded in a public UCC filing. Those filings are open records. Read one at a time they are administrative noise. Assembled, they describe something valuable: who financed which equipment, through whom, and roughly when that arrangement comes up for renewal or replacement.

I built a competitive intelligence platform that pulled UCC data in nightly and assembled it into a picture of each company's full equipment portfolio. What they held, what was coming off lease, what was due for renewal, what had recently been purchased. A sales rep could log in and see, for the accounts in their own territory, which machines were about to become decisions.

The access model mattered as much as the data. Visibility was segregated along the reporting structure, so a rep saw their own book rather than the whole market. That kept the tool usable instead of overwhelming, and it meant the leads that surfaced were leads that person could act on.

Qualified pipeline stopped being something the sales organization went hunting for and started arriving every morning, derived from records that had been public the entire time. It changed the growth trajectory of the business.

They flew me in during a downturn to make an offer

I had been an outside vendor for seven years when the 2009 downturn hit and the company began reducing staff worldwide. They flew me to headquarters and offered me a full-time position.

That is not the usual direction of travel in that kind of year, and it is the thing I would point to if someone asked what consulting is actually for. I had not been angling for a job. I had been running the systems the commercial business depended on, and when the organization got smaller, that was not work anybody wanted to lose track of. I took the offer.

How I ended up in the Salesforce ecosystem

In 2011 the origination platform was merged into Salesforce, and I joined the Salesforce team to do it.

That is how I entered this ecosystem. Not through a certification and not through a CRM job, but from the other direction, as the person who had built the system being replaced. That turned out to be the useful qualification. I knew which behaviors were load-bearing and which were accidents of how I had written them years earlier, and that is most of what determines whether a migration preserves a business or merely relocates it.

The estate Salesforce joined was substantial. Oracle R12, Siebel, SQL Server, ETL pipelines, enterprise document management, and custom applications serving parts of the business nothing off the shelf fit. I architected the integrations connecting those systems, which improved data quality and removed manual handoffs throughout.

CRM was one workload among several. Treating it as the center of gravity would have produced a worse architecture.

The competitive intelligence platform was not merged. It kept running on its own until the day I resigned, because nothing in the new estate did what it did, and nobody was willing to turn it off.

Twenty-six countries do not share a process

The applications I designed supported seven languages, and translation was the easy part.

The hard part is telling the difference between a local practice that exists for a real reason and one that exists because nobody ever revisited it. Credit works differently in different markets because the regulation and the risk are actually different. Account management sometimes works differently because a regional director once preferred it that way. Both look identical in a requirements document.

I was also not sitting in any of those countries, which sharpens the problem considerably. Context does not arrive on its own at that distance. Nobody stops you in a hallway to mention the thing you most needed to know. You go find it, repeatedly, from people who have no particular reason to spend their morning explaining their market to someone on another continent. The governance processes, development standards, and deployment methodology I established existed in large part to make that knowledge durable once I had gone and gotten it.

What eleven years teaches

I did not arrive junior and work my way up. I arrived as an advisor and the scope kept widening, from one application to the commercial platform to the region's architecture to the relationship itself.

That happened for an unglamorous reason. I built the systems, so I knew what the business actually did, and knowing what the business actually did made the technology recommendations obvious. The advisory role and the hands-to-keyboard role were never in tension. They were the same job observed at different distances.

Enterprise architecture is not the practice of implementing software well. It is the practice of understanding a business well enough that the decisions become clear, then holding enough trust to make them before they get made somewhere else.

This case study describes work performed for a global equipment finance organization. Client name withheld.