Most solar engineering teams do not slow down all at once. Throughput erodes quietly — a few extra hours per project, a growing queue of revisions, a design lead who has quietly become the bottleneck for every layout that ships.
The hard part is not fixing a slow workflow. The hard part is noticing that it has become one before it starts costing you deals. This guide walks through the concrete signals that a solar design process has outgrown its manual roots, and what to look at first when it has.
What does a workflow "at capacity" actually look like?
A workflow at capacity is not one where people look busy. It is one where the same person is required for every project to move forward, and where the time between "we have a site" and "we have a layout the client can react to" has crept from hours into days.
Three patterns tend to appear together:
- Turnaround time grows even though the team has not shrunk.
- Senior engineers spend more of their week on repetitive layout work than on review.
- Small scope changes trigger a disproportionate amount of rework downstream.
Which tasks are actually eating the time?
Before automating anything, it helps to separate the work that genuinely needs an engineer's judgement from the work that only needs their hands. In most pre-sales solar workflows the second category is far larger than teams expect.
Signal vs. noise in the design queue
Cable routing, bill-of-materials generation, and string sizing are deterministic once the constraints are known. They feel like engineering because an engineer does them, but they are mostly transcription — and transcription is exactly where accuracy quietly degrades under time pressure.
If your best engineer is the only person who can produce a client-ready layout, you do not have a workflow. You have a dependency.
How do you build the case internally?
Framing matters. "We want new software" invites scrutiny of cost. "We are turning around 40% fewer quotes than we could, and losing the slow ones to competitors" invites scrutiny of the status quo. Anchor the conversation in throughput and win-rate, then work backwards to the tooling.
- Measure current time-to-first-layout across the last ten projects.
- Identify how many of those hours were judgement vs. transcription.
- Model the win-rate impact of halving that turnaround.
Key takeaways
- Slow workflows reveal themselves through single-person dependencies, not headcount.
- Separate judgement work from transcription work before automating.
- Make the business case in throughput and win-rate, not tooling features.
None of this requires a wholesale process rebuild. It requires being honest about where the hours actually go — and then removing the parts of the pipeline that never needed a human in the first place. For a closer look at how automated layout and BOM generation fit a pre-sales workflow, see our design automation overview.
Frequently Asked Questions
How long does it take to move from a manual to an automated workflow?
Most teams see meaningful turnaround improvements within the first few project cycles, because the earliest wins come from removing transcription work rather than changing how engineers make decisions.
Won't automation reduce design accuracy?
In practice the opposite is common. Deterministic tasks like string sizing and cable routing are where manual accuracy degrades under deadline pressure, so automating them tends to raise consistency, not lower it.
What is the first thing to measure?
Time-to-first-client-ready-layout across your last ten projects. It exposes single-person dependencies faster than any other single metric.
See it on your own project
Bring a real site and watch the layout, string sizing, and BOM come together in minutes.
Start a free trial