Managing jobs in Excel: the file that works, and the three places it breaks
Excel handles job and project tracking far longer than ERP vendors admit. But it always breaks in the same three places — and knowing which one you're in tells you whether you need a better file or actual software.
If you're looking for how to manage jobs in Excel, you almost certainly already have a file and want it to work better. This article isn't here to talk you out of it. It's here to show you what a file that genuinely holds up looks like, and to help you recognise which of the three breaking points you're at — because two of them you can fix without buying anything.
First: Excel lasts longer than you're told
People who sell ERP systems have an interest in convincing you the spreadsheet is the problem. It isn't. For a company tracking a handful of jobs at a time, with one person maintaining the file, Excel is the correct tool: it costs nothing, you can change it yourself the same morning the process changes, and you don't have to file a ticket to add a column.
The moment it stops working has nothing to do with row count. It has to do with how many people write to it and how many variants the product has. Two different thresholds, crossed at different times.
What a job file that works looks like
Before the breaking points, it's worth saying what separates a file that holds up from one that becomes unmanageable in six months. The differences are few, and almost all structural.
One row per job, not one sheet per job
The most common mistake is creating a tab per job by duplicating a template. Convenient in month one, impossible by month six: you can no longer answer "how many jobs are running late" without opening all of them. A file that works has one single table, one row per job, and sheets — if needed — are generated from that table.
Reference data lives in its own sheet
Customers, items, operations, rates: these don't get retyped into every job row. They live in separate sheets and get referenced. It's the only defence against the problem that kills these files — the same customer spelled four different ways, which makes any total meaningless.
Status is a closed list
Job status must come from data validation, not free text. The moment someone types "in progress", someone else types "In Progress" and a third types "started". From then on your filters lie, and nobody notices until it's late.
Planned dates stay separate from actual ones
Two columns, not one overwritten. It looks pedantic and it's the only thing that lets you know, at year end, whether you estimate well or badly. Overwriting the planned date with the real one deletes the single number that mattered.
The three places it breaks
A file built that way lasts a long time. Then it gives — and in my experience it always gives in one of these three ways, in this order.
1. More than one person
The first and most common. Two people open the file, one saves, the other overwrites. That's how you get the filename everyone knows — jobs_2026_FINAL_latest_ok.xlsx — and with it a permanent doubt about which version is real.
This point does not require custom software.A cloud-shared sheet with concurrent editing solves it. If this is your only problem, switch tools and stop here: you've fixed it for nothing.
2. Variants and the bill of materials
The second arrives when the product is configurable. As long as a job is an item and a quantity, a row is enough. When the job becomes "this product, but in that size, that material and with that accessory", a row stops being enough: you'd need a tree structure, and Excel represents those badly.
The symptoms are recognisable. Columns multiply to cover every option. Nested formulas appear that one person can read. Someone starts keeping a second file with the bills of materials, aligned to the first by hand. From here on, every new product variant costs office work rather than production work.
3. Configurable quotes
The third is usually what blows everything up, and also what costs the most without anyone measuring it. A quote for a configurable product is assembled by hand, inside a sheet two people know how to use. Every combination is another row. And because the price depends on those formulas, an error is invisible: you find it when the job is already closed at a loss, or when the quote reached the customer too high and the deal is gone.
People at this stage usually aren't looking for an ERP. They're looking for a configurator: something where sales picks the options and the correct price comes out, without going through whoever owns the file.
How to tell which point you're at
There's one signal worth more than any technical assessment, and it isn't about the file — it's about the people.
When someone starts keeping a second, personal file because they don't trust the shared one, the system is already over. From that point you don't have a file with problems: you have two versions of the truth, neither reliable, and an argument that reopens at every meeting.
As long as everyone writes in the same place — even while swearing at it — the file is holding. When they start defending themselves with private copies, it isn't.
What happens if you do move to software
The thing almost nobody says: the existing Excel file is the most valuable part of the project, not the obstacle. A file used for years contains the company's real rules — which fields actually matter, which exceptions recur, where mistakes always happen. It's a specification written in the field, and it beats any requirements workshop, where people describe the process they should follow rather than the one they do.
So work done well starts there: read the file, understand what it actually does, and build that. Not start from zero, and not ask the company to bend to a standard model — which is exactly why the system bought three years ago went unused while the real work carried on in Excel.
I won't improvise numbers here: the real ranges, the comparison against a standard subscription and the break-even point are in what a custom ERP costs. If you'd rather see how the work runs — custom ERP — or start from a reading of the file you already have, that first conversation is free and mostly exists to work out whether the project makes sense at all.
In short
- Excel for job tracking isn't a mistake: it's the right tool while one person owns the file and the product isn't configurable.
- The multi-user problem is solved by changing tools, not by buying software.
- Variants and bills of materials are where Excel starts costing you office work.
- Configurable quotes cost the most, because the errors surface after the job is closed.
- The real signal isn't file size: it's when someone starts keeping a private copy.
Frequently asked questions
Is Excel good enough for managing jobs?
Yes, and for longer than ERP vendors will tell you. For a company running a handful of open jobs at a time, with one person maintaining the file, Excel is the right tool: it costs nothing, you change it yourself the morning the process changes, and you don't need anyone's permission. Problems don't come from the number of rows — they come from the number of people and the number of variants.
How many jobs can one Excel file handle?
The right question isn't how many jobs, but how many people write to it at once and how configurable the product is. A file with hundreds of closed jobs and one person updating it is fine. A file with twenty open jobs and four people working in it is already in trouble.
Excel or Google Sheets for job tracking?
Google Sheets solves Excel's most annoying problem — concurrent editing — and for many companies that's enough. It doesn't solve the other two: product variants and bills of materials stay unmanageable, and configurable quotes still depend on whoever knows the formulas. If multi-user is your only problem, change tools before you change approach.
How do I know it's time to move to software?
The signal isn't file size. It's when someone in the company starts keeping a second, personal file because they don't trust the shared one. From that moment you no longer have a system: you have two versions of the truth and nobody who can say which is right.
Can we start from the existing Excel file?
It's the best way. A job file used for years already contains the company's real rules — which fields actually matter, which exceptions keep recurring, where mistakes always happen. It's a specification written in the field, far more reliable than any requirements workshop. The software gets built from there, not from scratch.
