Almost everything written about this role assumes a venture backed software company: product led growth, a self serve funnel, a modern data stack.
If you run branches, clinics, an agency or field teams, that advice does not transfer. The role still applies. What changes is how you recognise the need and who you should hire.
What is different about a non SaaS company
Your systems are older and stranger. There is a CRM, probably half configured, sitting next to tools nobody has audited in years. The hire has to work inside that rather than replace it.
The process is in people's heads. In SaaS the funnel is instrumented by default. Here, most of what happens is undocumented, so the first month is discovery rather than building.
Location or team is the unit that repeats. Branches, clinics, crews, offices. The same process runs in several places and drifts in each of them. This is the single biggest difference, and it is why a startup playbook fails here.
Nobody is going to rebuild the stack. Whoever you hire has to produce a result on what exists, not on what they would have chosen.
So when you read the symptoms below, you are checking whether the problem is engineering rather than headcount. The eight are the same in any industry. The hire that fixes them is not.
Run the list
1. Leads sit before anyone contacts them
An inbound lead arrives and waits hours, sometimes until the next business day. The team is not lazy. Nobody is watching the queue, or the lead landed somewhere that is only checked in the morning.
What it costs: the difference in conversion between a fast first contact and a slow one, on every lead, forever. It is the most expensive item on this list and the cheapest to fix.
2. Reps research instead of selling
The first minutes of every call go to looking things up: who is this, what do they have with us, what happened last time. The information exists. It is just not on the record in front of them.
What it costs: a fraction of every selling hour, plus the customer's impression that nobody is paying attention.
3. Follow up depends on somebody remembering
There is no second touch unless a person decides to make one. Deals close because a rep was conscientious, not because a system existed.
What it costs: the deals that needed a third contact and got one.
4. The same manual step repeats hundreds of times a week
Copying a value from one tool to another. Assigning by hand. Updating a spreadsheet after each call. Individually trivial, collectively a headcount.
What it costs: the salary equivalent of the hours, plus the errors that manual repetition guarantees.
5. Two teams run the same process differently
Both are sure theirs is correct. Both are partly right. Reporting sums two different definitions into one number that describes neither.
What it costs: every decision made on that number.
6. A second location means rebuilding
The pilot works. Expanding it means recreating the workflow with different fields, a different script and a different routing rule. Now there are two systems that drift apart.
What it costs: the rollout that keeps slipping, and a fix applied once that silently does not apply everywhere.
7. Nobody can trace revenue to its source
Money arrives and everyone has a theory. Nobody can walk backwards from a closed deal to the conversation, the campaign and the list it came from.
What it costs: you cannot cut what is not working, so you keep paying for all of it.
8. Reporting is assembled by a person
Someone spends part of Monday building the number for the meeting. By the time it is presented it is days old, and everyone quietly knows it.
What it costs: the hours, and a leadership team steering on stale data.
What to do with the result
Count your yeses. One or two: fix them directly, they are probably specific and small. Three or more: you have an engineering problem, and hiring capacity against it will produce more activity at the same revenue.
Weight two items above the rest. Leads sitting untouched costs you deals today. Untraceable revenue means you cannot decide what to stop, which compounds every quarter you leave it.
And if the honest answer is that nobody has written the process down, start there. Automating a process nobody can describe does not fix it, it makes it confusing faster and at scale.
What to look for in the hire, specifically
Someone whose portfolio includes work inside systems they did not choose. That is the whole test. A person whose experience is building clean stacks from scratch will spend your first quarter proposing a rebuild.
Ask them to describe a deployment across more than one location or team. If they have done it, they will talk about configuration rather than about building, and that is the answer you want.
The people who do this work
MitHub keeps open profiles of GTM engineers and forward deployed engineers with their deployments written out: the problem, the approach, what was built and what it produced. Browsing and contacting them is free.