One of our clients put it precisely and without ceremony: "What does 'in the order of weeks' mean, that is the question." He wrote it in August 2026, in the middle of work in progress, and he wrote it because one part of his operation was starting to burn and he needed to know when he could count on it.
The question is the right one, and the answer to it usually is not what either side thinks. "In the order of weeks" is, as a rule, not an evasion. It means the supplier genuinely does not know at that moment, and the only honest thing is to ask what exactly it is they do not know.
This article promises no deadline. It shows how to turn an estimate into something you can check as you go, without having to understand the technology.
Why it gets said
Three reasons, and only one of them is a bad one.
The scope is not finished. In automation the full scope is almost never specified up front, because some of the exceptions only appear in the data. So the supplier is estimating work whose size they do not yet know themselves. That is a normal state of affairs, but it has to be said out loud - see below for what it looks like when it is not.
They are waiting on input from the customer. Access, document samples, the IT administrator's approval, a decision nobody wants to make. This part of the deadline is not in the supplier's hands at all, and it tends to be the single item that moves everything else.
And the bad reason: the supplier has more work than they can carry and does not know when they will get to you. You recognise it because the estimate repeats unchanged - "in the order of weeks" a month ago and "in the order of weeks" today.
A deadline without a measurable output is not a deadline
A date on its own means nothing, because on the day almost anything can be declared done. A usable deadline has three parts, and if one is missing the whole thing is:
- A stage. A bounded piece that makes sense on its own.
- A mark of completion. A sentence that can be ticked off without discussion. Not "the module works" but "ten out of ten of your documents go through and the result matches your spreadsheet".
- What happens if it slips. Who tells whom, by when, and whether only this stage moves or all the following ones too.
The third point is the one that never gets written down, and it is the one that decides. A slip is not a failure - the failure is a slip the customer hears about on the day it was supposed to be finished.
Scope changes quietly. Our own example
The most common cause of a slip is not laziness or incompetence but the brief inflating during the work while nobody says the words "extra work" out loud.
Our own case from 2026. For one client we estimated the content part in the proposal as "a couple of articles, a couple of pages and basic meta tags". In reality the edits touched almost 140 pages. The estimate was not invented - it followed from what was visible at the time. Not much was visible.
Scope usually changes in three ways, and all three look innocent:
- Exceptions accumulate. Every further "and also when this happens" is one more scenario, not one more condition.
- The number of affected places grows. Not features, but the count of pages, documents, branches or records the change touches.
- The priority changes. What was first becomes second because something else caught fire. That is a legitimate decision; it just has to be visible what it pushed back.
When a deadline slips, it has to be said before it passes
A second example of our own, this time with no excuse.
On 10 February 2026 we named specific days to a client on which part of the work would be done - not "in the order of weeks" but "this Thursday to Friday". On 10 March 2026 the client wrote that it should have been finished almost four weeks earlier. He was right. We named the cause ourselves: an advertising campaign took priority and the rest of the brief was pushed back.
What the article recommends follows from that case, and it follows from a mistake rather than from a maxim: a slip has to be reported by whoever caused it, and reported before the deadline passes. A customer who works out the slip for themselves, late, starts checking everything else - and has a reason to.
That case also explains why the article contains rules rather than promises. We named the specific days and we were the ones who missed them. The difference between a good course of events and a bad one was therefore not whether a deadline was named but what happened as it approached and the work was not done.
How to turn an estimate into a plan you can check
You do not need to understand the technology for this. You need four columns and one meeting at which you fill them in with the supplier.
| Stage | When | How I know it is done | Who it depends on |
|---|---|---|---|
| Collecting samples | week 1 | I have the list of what to supply and I have supplied it | me |
| End-to-end run | week 2 | one of my documents goes the whole way through | the supplier |
| Exceptions | week 3-4 | the list of exceptions is written down and priced | both |
The "who it depends on" column is the most important one in the table, because it divides responsibility before anyone starts looking for someone to blame. The stages that depend on you come first in most projects, and they are usually the ones that move everything else.
The practical consequence: when a supplier says "in the order of weeks", do not ask for a date, ask for the first stage with a measurable output. A deadline two days out is always truer than a deadline two months out, and four of them in a row give you a picture you can actually check.
Six questions that turn an estimate into a commitment
- What exactly will I have in my hands first, and when?
- How will I know that thing is finished without having to take your word for it?
- Which stages depend on me, and what exactly do you want from me?
- What part of the scope do you not know yet, and when will you know it?
- When and how will I hear that the deadline is slipping?
- If it is late, does only this stage move or all the following ones as well?
An estimate in weeks is an honest answer to the question "how long does it take". It is not an answer to "when can I count on it". That one is made of stages, marks of completion, and an agreement about what happens if they are missed.
With us you get stages, not a single number
We fix the scope of an automation stage by stage, and the mark of completion goes into the brief rather than only into the acceptance record. If the first stage shows that the next one is not worth it, we will tell you - even when that means a smaller job.
What we automate and to what extent is on the business process automation page. Connecting to business systems we describe separately under CRM and ERP.
Write to info@lamapixel.com or call +420 775 599 009.
