George Eliadis

The through-line

Everything George Eliadis says circles one claim: dispatching is a data problem being solved by tired humans in real time, and that gap is where the money leaks. His description of the job is a game of Tetris played under interruption, where "you'll have 40 technicians out in the field" and "152 jobs to to play Tetris to play chess and reshuffle" while customers call asking where their technician is and technicians call asking for their next job [1]. ProBook exists to take the assignment half of that off the board and replace mental heuristics with expected value calculated from history [1]. The second, equally insistent thread is that a company selling into the trades earns its right to that automation through physical presence and obsessive support: the product was, as the framing of one conversation puts it, built in the trenches with contractors rather than in a lab [5], and Eliadis describes launching every customer on site and answering dispatchers in seconds [1].

On what a dispatcher is actually optimising

He is precise about the job rather than dismissive of it. A dispatcher is holding three things at once: data-driven assignment, routing, and the human load of customers and technicians. "To be a dispatcher you have to be really hardcore and you just have to be able to to get pulled in a million different directions and not not crumble" [1]. His diagnosis is that at scale one or two of the three always gives: "either you make decisions that are not data driven that costs a company money you're either neglecting customer experience because the board is so hectic that only thing you can do is match jobs to text or your technicians feel unsupported" [1]. That framing explains the product roadmap. Assignment came first, then automatic customer updates, because those are the two pressures that crowd out judgment.

He is explicit that ProBook does not remove dispatchers: "you still do need dispatchers because setting the board and assigning calls is just one part of the problem" [1]. Customers still need talking to, technicians still need debriefing. The ambition is incremental absorption of the function, "we're going for more and more parts of the dispatcher function so we could with time make ProBook actually help uh companies operate with you know less dispatchers um for their set of technicians" [1]. He has also worked through what dispatching at scale looks like as a revenue lever rather than a scheduling chore, framed as "dispatching for dollars", and how a shop that already tracks its numbers turns them into smarter scheduling, fewer reschedules and higher revenue per truck [2][5].

On expected value as the unit of the decision

The core of the system is a per-technician, per-job-type forecast. For a given call, say a twelve-year-old HVAC system that is not cooling, ProBook looks at "exactly how much each Tech is sold at that type of job" and then adds downstream value from tech generated leads: the recommendation a service technician makes for a comfort advisor to assess replacing an ageing system [1]. Repair sales plus TGL sales give a single number per technician for that job, and driving time is folded in alongside. The board is then reshuffled continuously: "we're actually reshuffling your dispatch board in real time and reoptimizing it as new calls arrive so the chess is always being maximized for what we call Ev or expected value between all of your Tech I and all of their performance histories" [1].

He also draws attention to why replacement is often the honest recommendation, not just the lucrative one: on a system over ten years old it "may not make Financial sense to actually invest more repairs into it it might just make sense to get piece of mind and replace it all together" [1]. The point is that this judgment is already being made in the field, and the dispatch decision determines who makes it.

On where the AI actually sits

He resists a vague answer here and breaks it into layers. Machine learning forecasts job value per technician using job type and Service Titan tags, "those tags are basically attributes that help us appraise the value of a certain job", and separate models forecast operational metrics such as "how long do texts take on average at a given call" [1]. On top of that sits a generative layer that reads unstructured history: "we can now actually go into invoice notes on past jobs job summaries" [1]. The next build is transcribing calls between CSRs and homeowners, and the reason is a data reason rather than a novelty one: better labelling means "our machine learning model can value them better because we'll have more features that are automatically lab" [1]. The direction of travel is that every unstructured artefact in the business becomes a feature for the valuation model.

On simplicity being the hard part

For all the machinery underneath, the experience he is chasing is a board that appears to move by itself. He accepts the comparison to watching a video game play itself: "you just put it on a it's like the video game you just have the AI bot playing the video EX it's like you're playing CPU" [1]. The complexity is real across software, AI, product and operations, and none of it is supposed to reach the dispatcher [1].

On growing deliberately slower than you could

Asked how growth feels, his answer is that they throttled it: "we've actually had to like put a pause on growth because we need to like we need to get our stuff together internally and hire some some customer success people because we're we're growing so fast and we don't want our experience to suffer" [1]. He treats the support standard as an obligation created by the promise, not a nice-to-have: "that's a reason why people work with us and so we it is our responsibility Our obligation to maintain that" [1]. He started selling roughly six months before the conversation, after a beta period that he characterises as unpaid because "our product had a we had a lot of learning to do" [1].

On support as the product

Two practices carry the customer experience. First, in-person launches: "we actually launch every single customer we work with on site", with weeks running through South Carolina, Delaware, New Jersey, Virginia, Ohio, Wisconsin, Massachusetts, Georgia, Minnesota and Oklahoma [1]. Second, support inside the customer's own tools rather than a ticket queue. Every customer creates a Microsoft Teams, Slack or Google Chat channel joining their dispatchers to the ProBook team, and his benchmark is a Saturday evening question from a dispatcher in Florida "fully acknowledged in like 12 seconds" and "resolved in 60 seconds" [1]. He calls this the secret to good support at their stage and expects it to stop being a secret [1]. The same instinct shows in how the product was developed, alongside contractors and inside real operations including ride-alongs in TR Miller's call centre and dispatch room [5].

On hiring for customer obsession

The growth pause pushed him into a role he had not held before. "I'm like a full-time recruiter like I've had to step away from the customer stuff a little bit because it's like our customers are a number one priority but if we don't build a team more like the customers are going to going to be hurt" [1]. His filter is temperament rather than credential: "I want to find the right person that's going to you know going to take offense when there's a customer question that's gone unanswered", the "most like inquisitive proactive like questioning people", and he names the reason plainly, "customer obsession is exactly how we've got here" [1]. He is candid that the stress is real and that he had never recruited before [1].

On the trades as a market

He is warm about the industry itself and its appetite for new tools, pointing to the entrepreneurs and early adopters who "kind of get the what it takes to like build one like a business and and scale it and grow it" [1]. Contractors, not investors, drove his early distribution: an introduction from a customer led to conferences, and one customer visit cost him a course at university, which he salvaged by writing a final project on private equity activity in the space [1]. He has also gone on record about what place technology holds in the trades and how that will change over the next few years [3][4], and his own route in ran through a pressure-washing side hustle in New York before ProBook [5].

Takeaways

• Dispatching fails at scale because one person is optimising three things at once, and something always gives: data-driven assignment, customer experience, or technician support [1].
• The assignment decision should be an expected value calculation per technician per job type, combining historical repair sales, downstream tech generated lead sales and drive time, recomputed as new calls arrive [1].
• Machine learning forecasts job value and job duration; generative models mine invoice notes and job summaries, and call transcription is being added to improve job labelling so the valuation model has better features [1].
• Automating assignment does not eliminate dispatchers, it frees them for customer updates and technician debriefs; automatic "your technician is running late" texts cut inbound calls asking where the technician is [1].
• Growth was deliberately paused so customer experience would not degrade before customer success hiring caught up [1].
• Support runs through the customer's own Microsoft Teams, Slack or Google Chat channel, with acknowledgement in seconds and resolution in about a minute even on weekends [1].
• Every customer is launched on site in person, which he treats as the reason the experience holds [1].
• Hire for people who take a missed customer question personally rather than for volume [1].