How to scale a solar EPC business from 20 to 50 projects a month

You scale a solar EPC business from 20 to 50 projects a month by making the state of every project visible, not by hiring in proportion to the growth. Your site surveyors and sales staff will not double in number, yet the coordination work will triple. The bottleneck is not the people on site—it is the state of each project sitting in email and conversation history instead of a single source of truth. Every stage of a project has tasks that must happen in sequence: documentation, loan application, site survey, procurement, delivery, installation, net-meter activation, completion. When you have 20 projects, a manager can hold the status in their head. At 50, you cannot. The projects that stall do so silently until a customer calls.

Define every stage and write tasks automatically

A rooftop solar project in India runs through 15 working stages, from site qualification to completion, with two end states (complete and cancelled) beyond them. Each stage has tasks that must finish before the stage can close.

When a project moves to the loan stage, your ops team now has to remember to request the documents, follow the bank, restamp if details shift, collect the sanction letter. None of that happens on time unless it is written down with a due date. The system should write every task automatically when the stage opens, with due dates calculated from the stage entry date: document verification a day out, the loan-application paperwork a day out, a loan-sanction check-in four days out. That check-in date is not how long a bank actually takes; the median runs closer to a month. It is when the desk should first look, and keep looking while the task sits open. A task is not done until closed; a stage cannot move forward with open items.

When we ran this for a Delhi EPC, loan sanction was consistently the visible bottleneck in the pipeline, from that EPC's own stage data. But the real bottleneck was that nobody knew the application was stuck until well into the wait, when the customer called. With written tasks and due dates visible to the ops team, the first task due was "collect full documentation" on day 1. The moment a task went overdue, it started climbing the org chart automatically, one rung a night, without anyone having to remember to chase it. Visibility forces action.

Route escalations through the org chart, never email

Overdue work should climb the org chart automatically every night, not wait for someone to remember to email. A task overdue by a day escalates to the assignee's manager. Overdue by two days, it reaches that manager's manager. It keeps climbing one rung a night until it sits with the director. No one can forget; no one can claim they did not know.

Green-text conversations and WhatsApp messages feel fast. They are not. A telecaller books a site visit, messages the salesperson, who messages the delivery ops, who sends a note to the driver. Somewhere in that chain, the driver was never told. The visit did not happen. No one knows why until the customer calls.

The written task is the contract. One document sits at one person's desk. If they mark it done, it moved to the next step. If they do not, the system knows they are stuck and raises it up. At one Delhi EPC running a large book of active projects, nearly every checklist task on record had been written automatically by the system rather than typed by hand, spanning procurement, delivery, installation, documentation, compliance and payment gates. Its task on-time rate climbed markedly over the following months — a real gain, though not yet a clean, steady climb.

Separate the roles and make every screen purposeful

When you have 20 projects, one person often wears five hats. At 50 projects, that person will drown. You need a documentation ops role (owns the customer papers and verification), a delivery ops role (owns the material on site), a QC ops role (owns the inspection), a telecaller role (books visits), a sales staff role (closes deals).

Every role has a first screen that shows only their work. An illustrative example: a documentation ops person logs in and sees "40 projects waiting for document verification", "5 projects with missing pages", "12 documents marked incorrect, awaiting re-upload". They do not see the sales pipeline or the delivery schedule. A delivery ops person, in the same illustrative scenario, sees "30 projects waiting for material dispatch approval", "8 sites cleared for installation", "2 sites with access issues". The screen tells them what to do today.

Automate the visible, trackable parts

A telecaller should not chase paperwork or decide payment status. The system should know when a project is clear to dispatch—documentation is verified, payment gate is crossed, delivery slot is available. The system tells the telecaller which site visit to book and when. The telecaller books it, notes the date, and walks away. If the visit does not happen, the task stays open and escalates.

Site visit outcomes should flow back into the system. The telecaller says "visit confirmed for 10 September". The system moves the project toward the site survey stage. The telecaller says "customer is asking about financing". The system flags that the loan application task is not yet started. No information is lost in the handoff.

The loan sanction delay is not the bottleneck you can fix

It feels like the whole schedule waits on the bank. At one Delhi EPC, loan sanction was consistently the slowest stage in the pipeline: a real, bank-side wait, from that EPC's own stage data. But your ops team should be working through everything else in parallel, on the same data: document collection, site survey, structure dispatch and material dispatch are all comparatively quick stages when nothing is stuck. Run those stages alongside the bank's clock and the wait costs you nothing. Let your documentation drag because nobody was sure what the customer submitted, and the bank's thirty days will not save you—you already lost the time yourself.

The real bottleneck is the tasks you can control. With visibility into what is stuck and why, you can reorganise the order of work, split projects by loan vs. non-loan path, or bring in a contractor to push a backlog through. You cannot do any of that without seeing the state.

How to scale a solar EPC business without hiring proportionally

At 20 projects a month, you have a director, a general manager, one ops person, two sales staff. At 50, you do not hire 2.5× more sales staff. You hire one more ops person (documentation) and one more (delivery). You might hire a telecaller if you want to qualify leads over the phone before your sales team drives out. You keep the general manager; they now see the state in the system instead of managing by walking around.

The sales efficiency typically improves, not decreases, during a 2.5× scale. Why? Visibility. A salesperson now knows if a customer's paperwork is stuck, so they can call and push it. They know if a delivery is overdue, so they can reset the customer's expectations. They know if the previous quarter had projects stuck waiting on the net meter, so they can push those applications in earlier next time.

One Delhi-NCR rooftop EPC we work with grew won orders steadily over a few months, adding a single operations hire in that stretch: a third documentation ops person. The director, general manager and a two-person sales team stayed as they were until a third salesperson joined later in the year. Installations completed rose sharply over a couple of months before easing back — a normal pattern, since a pipeline this size moves in bursts rather than a straight line.

The tool makes visibility the default state

This is not achievable with a spreadsheet or a WhatsApp group. A spreadsheet is a snapshot; it is out of date by the time it is read. WhatsApp is a conversation; it leaves no record once someone clears the chat. The system must be the state. Every team member logs in to one app, sees their tasks, marks them done. No retyping, no missing updates.

A system like Solar Spine writes tasks automatically when a stage opens and escalates overdue items every night. Every role sees only their work. Payment gates, document gates and stage-exit rules are recorded in the system, not in someone's head. Handoff points are visible and checkable. If the telecaller is supposed to book the site visit and did not, the operations head knows the next day because the task is there.

This is not bespoke. You can build this with a database, a rules engine and discipline. You can also use software built for solar EPCs that has the stages, task types, roles, and escalation logic already shaped to your business model, such as Solar Spine's pricing. The cost is usually less than the salary cost of the ops person you would otherwise hire to manage the confusion.

Scaling from 20 to 50 projects a month is feasible if you make the state visible. The alternative is hiring staff to do nothing but synchronise information in email, or accepting that half your work is overdue at any time. See the full numbers for what that looked like at one Delhi-NCR EPC.

Sources: operations data from a live Solar Spine workspace; author ran this team scaling from 20 to 45 projects monthly at a Delhi-NCR EPC.