Ask a practice manager how the firm’s technology is performing and you’ll get an adjective. Fine. Slow. Better than it was. Frustrating lately.
Ask for a number and the conversation usually stops.
That’s not a criticism — nobody hands architects a set of IT benchmarks when they open a practice. But it creates a real problem, because you cannot manage what you don’t measure, and “it feels slow” is impossible to act on, budget for, or hold a provider accountable to.
What follows is a set of numbers worth knowing about your own firm. Some you can establish yourself this week. Others require asking your provider. Together they’ll tell you more about your actual position than any proposal ever will.
The benchmark table
Here’s the shape of it before we get into detail. These are the figures we’d expect to see at a well-run architectural practice.
| Metric | Poor | Acceptable | Good |
| Patch compliance | Under 70% | 85–95% | Over 98% |
| Days since last restore test | Never / unknown | Within 6 months | Within 90 days |
| MFA coverage | Partial | All staff | All staff, no exemptions |
| Help desk first response | Next day | Within 2 hours | Under 15 minutes |
| Issues resolved remotely | Under 50% | 70–85% | Over 90% |
| Storage utilisation | Over 90% | 70–85% | Under 70% |
| Model sync — quiet vs busy | 3× slower | Under 2× slower | Under 1.5× slower |
| Recovery points retained | 1 (last night) | 7 days | 30+ days |
| Monitored devices | None | Servers only | Everything |
If most of your firm’s figures sit in the left column, that’s worth knowing. If most sit in the right, you’re in better shape than the majority of practices we assess.
Number 1: Patch compliance
Target: above 98%.
This single figure tells you more about whether anyone is actively maintaining your environment than any other metric. It’s the percentage of your workstations and servers running current, fully updated software.
In practices we assess, it routinely sits between 55% and 70% — almost always accompanied by the entirely reasonable belief that Windows Update was handling things automatically.
Windows itself is usually the better-maintained part. The gaps are in third-party software: PDF readers, browsers, Java, and the various utilities that accumulate on design workstations over the years. Those happen to be among the most commonly exploited applications on any network.
How to find yours: ask your provider directly. If nobody can produce a percentage, that absence is itself the answer — it means nothing is being measured, which means nothing is being managed.
Number 2: Days since your last restore test
Target: within 90 days.
Note the phrasing. Not days since a backup ran. Days since someone actually restored something and confirmed it worked.
The distinction is the entire subject. A completed backup job confirms one thing: the job ran. Corrupted data backs up perfectly well, and we have tested backups completing cleanly for four years that failed entirely when a restore was finally attempted.
There’s a second question that goes with this one, and it may matter more: could ransomware on your network reach the backup? Modern ransomware specifically hunts connected backup storage, because attackers know a firm that can restore doesn’t negotiate. A backup drive in the server room, reachable from any workstation, gets encrypted alongside everything else.
For a practice, this is existential rather than inconvenient. Ransomware reaching your model storage doesn’t delay one project — it stops every active project on the same morning.
Proper backup and disaster recovery means daily automated verification, off-site replication, and testing on a schedule that produces a written result.
Number 3: MFA coverage
Target: 100%, with zero exemptions.
Most firms will tell you they have Multi-Factor Authentication. Fewer can produce a report showing it enforced on every single account.
The failure mode is almost never total absence. It’s partial coverage — two or three senior people exempted during a busy period because they found it disruptive, and nobody revisited it afterward.
Those accounts hold the broadest access and carry the most authority. Attackers look specifically for the exceptions, and finding them is rarely difficult.
Worth knowing: 100% is the only acceptable figure here. There is no meaningful difference between 90% coverage and a marked map.
Number 4: Help desk first response
Target: under 15 minutes.
The technical problem might take ten minutes to resolve. If reaching those ten minutes means leaving a message and waiting for a callback, your cost isn’t the ten minutes — it’s however long it sat unresolved.
For a practice, this bites hardest at the worst moments. Someone can’t open a model an hour before a client presentation. A consultant’s files won’t transfer on the afternoon a coordination set is due.
How to find yours: ask your provider for last quarter’s average. A provider measuring their own performance will have the figure available. One that doesn’t measure will explain why measurement is complicated.
Number 5: Percentage resolved remotely
Target: above 90%.
This tells you something about capability rather than convenience. A high remote resolution rate means your provider has the tooling and access to fix things without travelling — which is why response times can be measured in minutes rather than days.
It also removes distance as a factor entirely. A firm in Stockton and a firm in Sacramento get the same response, because nobody is driving anywhere.
Number 6: Storage utilisation
Target: below 70%.
Storage performance degrades noticeably as capacity fills, long before anything actually breaks. Above 85%, everyone feels it. Above 90%, backup windows stretch and problems start compounding.
But there’s a more important distinction hiding here, and it’s the most expensive misdiagnosis in the whole category.
Capacity and speed are different problems. Capacity is how much fits. Speed is how quickly storage responds when several people access it simultaneously — which is exactly what happens with central models and shared project files.
A drive that’s half empty and slow under concurrent load will throttle your entire team, and adding space changes nothing at all. If your provider’s answer to slowness has been “we’ll add another drive,” that’s worth revisiting carefully.
Number 7: The sync ratio
Target: busy-period sync under 1.5× the quiet-period time.
This is the most useful number on the list, and you can establish it yourself in five minutes without involving anyone.
Time a central model sync early in the morning, when nobody else is working. Then time the identical operation around 11:45, when several people are likely syncing at once.
Divide the second by the first.
Under 1.5 — your shared infrastructure is coping. If things still feel slow, look at workstations or model complexity.
Around 2 — concurrent load is starting to bite. Worth investigating before it worsens.
Over 3 — the bottleneck is shared, sitting in storage or network. Individual workstation upgrades will change almost nothing.
That last scenario is where firms spend heavily on new machines and see barely any improvement, because the new hardware waits in exactly the same queue the old hardware waited in.
Number 8: Recovery points retained
Target: 30 days or more.
This one catches people out, and the reasoning is worth understanding.
Attackers frequently sit inside a network for weeks before triggering encryption. If your only clean copy is from last night, it may already contain their tools. Firms restore successfully, resume work, and get encrypted again ten days later from the infection they carefully preserved.
Multiple recovery points spanning several weeks is what lets you go back past the date a problem actually began.
Number 9: Devices under monitoring
Target: everything.
Not just servers. Workstations, network equipment, storage — all of it, watched continuously.
This is the figure that determines whether problems reach anyone technical before they reach your staff. In an unmonitored environment, a drive reporting errors for six weeks produces no warning at all until it fails, and the weeks an attacker spends mapping your network pass entirely unnoticed.
You cannot call someone about a problem you don’t know you have. Continuous monitoring is what converts invisible problems into early warnings, and it’s the structural difference between reactive and managed support.
The number nobody calculates
One more, and it’s the one that usually settles the argument internally.
Ask three or four people to note, over a single week, roughly how many minutes they lose daily to waiting — on syncs, on file opens, on renders competing for resources, on something needing a restart. Don’t formalise it. A rough figure is enough.
Then run the arithmetic. Eight people losing thirty minutes each is four hours a day. Across a working year, it approaches the equivalent of a full-time position that produces nothing.
You’re already paying that. It just doesn’t arrive as an invoice, which is precisely why it survives budget reviews that would eliminate a far smaller line item.
Where this is heading
Worth noting a trend that will make these numbers matter more over the next few years, not less.
Public sector clients and larger private organisations increasingly send security questionnaires to their design consultants — sometimes as part of procurement rather than afterward. They ask about MFA coverage, backup testing dates, patch management, and monitoring. Insurers ask the same questions at renewal, and the application is a legal document.
Firms that can answer with figures are winning work against firms that can’t. Neither side is aware of it happening, because nobody is told they lost on security grounds. They simply aren’t shortlisted.
The practices that maintain these numbers properly find each renewal and each questionnaire easier than the last, because the evidence already exists. The ones treating each request as a one-off scramble annually.
Getting your own figures
Three of these you can establish yourself this week: the sync ratio, storage utilisation, and the rough time-lost estimate. None require technical knowledge.
The rest need asking. Take them to whoever manages your technology and request specific numbers rather than reassurances — a percentage, a date, a coverage report.
What you get back tells you two things. It tells you where your firm actually stands. And it tells you whether anyone has been measuring at all, which is frequently the more revealing answer.
Ask us for your numbers. We’ll measure the ones you can’t establish yourself, produce a written figure for each benchmark above, and tell you plainly which gaps are worth closing for a practice your size — and which genuinely aren’t. Call 209-920-4077 or arrange an assessment for your Stockton practice.
