Skip to the content

Case study

Why your video tool promises a day for a job ready by evening

A finish time built on one fixed rate is furthest from the truth on the biggest jobs, while the counter beside it can sit at zero. What we found on a client's video platform, and what to check on yours.

Key takeaways

  • A finish time built on one fixed rate is furthest from the truth on your largest jobs, which are the ones your team plans around.
  • A counter can sit at zero for hours while the work behind it is healthy, so ask what it counts before treating a job as broken.
  • An estimate that follows each stage and reads the job's own recent pace can be checked against jobs that have already run.
  • A real stall has to look different from slow progress, or someone will restart a job that was running fine.
  • Test any estimate on your longest jobs first, because that is where a fixed formula is likely to be furthest out.

The editors on the video platform we build for a client now see, for every ad in production, about when it will be ready, where it is, and whether it is moving, and the change went live the same afternoon the owner asked for it. What changed was the finish time. Video tool progress stuck at zero had been the visible symptom, but the estimate beside it was the part that made planning impossible.

What a wrong finish time does to a team

A finish time is not a small display issue: people schedule around it. When the screen promises a day for a job of a few hours, the team puts off work it could have slotted in, tells a colleague to wait, or moves on to something else. A counter stuck at zero adds a second problem: it looks like a broken job, and a broken-looking job gets restarted. A restart loses the hours already spent and the job's place in the line. Once a screen has been wrong a few times, people stop reading it and ask a person instead, which puts the answer back in one person's head.

The symptom: a finish time a day away, with video tool progress stuck at zero

One of our clients makes its ads on a video platform we build for them, and one morning its editors could not tell whether a long job was alive. A sales video close to half an hour had been in production for hours. Its page showed zero clips out of several hundred for about four hours in a row, and beside the counter it promised the video in about twenty hours. Neither number was true: the presenter's clips were coming in steadily the whole time, and the video was ready the same day. What the team could not do was plan around it: whether to wait, start something else, or say when the ad would be out.

What our engineer found

The time promise came from one fixed rate per line of script, set when videos were short, multiplied by the lines of a very long script. It knew nothing about the step the job was in, the clips already made, the pace of that day, or the jobs ahead in line. The counter had a separate problem: it was counting finished scenes, and the platform writes scenes only once every presenter clip is in, at the very end of that step, so it showed zero for the whole presenter stage however much work was done. The final drawing had a surprise of its own. A long video is now drawn in parts at the same time and then joined, but the old formula still assumed the whole drawing happened in one go, so it said nearly two hours for work that takes about forty minutes.

What we changed

We replaced the formula with an estimate that follows the job through four stages as the team sees them: waiting in line, the presenter's clips, the edit, and the drawing of the final video. While a job waits, the estimate looks at the jobs holding a place and those ahead of it, and at how fast the platform is making clips. During the presenter stage it counts the clips still needed, including the planned extra takes of the opening lines and a small share of retakes, takes away those already made, and divides by the job's own pace over the last half hour, so a busy day shows up as a later finish. For the final drawing it times the work as it now happens: the parts at the same time, then the joining, with every rate checked against jobs the platform had really run in the days before. The page now shows a card with the time the video should be ready in the viewer's own time, the time left, and a bar in four parts sized by how long each part takes, with the current one moving. It says when clips are waiting for someone's review, when a job is set to finish by hand, and when no new clip has come in for twenty minutes, so a real stall looks different from slow progress. The ads list shows a short line and a thin bar for every ad being made, and the clip counter now counts presenter clips actually made, with the pace per hour.

What came of it

On the long video we checked, the final drawing was estimated at a little under forty minutes while its parts were still being drawn, and it took about forty minutes, where the old formula had said nearly two hours. The timing of long videos was corrected within a few hours after that video was drawn, and the page carries the new estimate from then on.

What you can check yourself

  • Open the progress screen of your longest running job and ask what its number actually counts. If it counts output that appears only at the end of a step, it will sit still while work is happening.
  • Compare the finish time your tool promised for your last three long jobs with when they really finished. A promise that misses by a wide margin on your biggest jobs is the sign.
  • Look at whether the estimate changes on a busy day. If it says the same thing every time, it is not reading the pace of that day.
  • Look at how a stalled job appears next to a slow one. If both look the same, nobody can tell them apart.
  • Ask whether the screen shows which stage a job is in. One number for a job with four stages hides the work between them.

What to do next

Start with your longest job rather than your shortest, because that is where a fixed rate is furthest from the truth. If the numbers belong to a tool you use, keep a short note of the time promised and the time the last few long jobs really took, and give it to whoever looks after that tool. If they belong to something built for you, the same note is what starts the conversation. Until the estimate is fixed, do not restart a job that looks stuck: ask first whether clips or output are still arriving, because a restart loses the work already done and the job's place in the line. Following a job stage by stage, and checking the estimate against jobs that have already run, is the kind of work our engineers do for clients.

Questions people ask

Why does my video tool show zero progress while it is clearly working?

The number is often counting an output that appears only at the end of a step, such as finished scenes written once every presenter clip is in. For the whole of that step it can sit at zero while plenty of work is happening. Ask what the number counts before you treat the job as broken.

Why is the finish time so far from what really happens on long jobs?

A single fixed rate per item, set on short jobs, is multiplied by the size of a long one, so small inaccuracies become large. That kind of estimate usually knows nothing about the stage the job is in, how fast it is moving that day, or the jobs ahead of it. It is furthest out on the jobs your team plans around.

How can I tell a stuck job from a slow one?

Look for a signal that can only come from the work itself: clips arriving, a file growing, a stage changing. A screen that shows the same zero in both cases cannot help you. If nothing changes and there is no separate warning about a stall, ask whoever looks after the tool before doing anything.

Should I restart a job whose progress bar has not moved?

Not on the strength of the bar alone. A restart loses what has already been done and the job's place in the line. Check whether output is still arriving, and ask the person who looks after the tool if you cannot see it.

How accurate can a time estimate for a long automated job be?

Closer than a fixed formula, and never perfect. An estimate that follows each stage, reads the job's own recent pace and is checked against jobs that really ran can land close; on the long video we checked, the final drawing was estimated at a little under forty minutes and took about forty minutes. Any estimate is only as good as the day it is reading.

From Tech Concierge

Want this handled for your business?

Your own engineer builds and runs the website, the app, the CRM and the AI assistant that answers your customers.

The first 7 days are free.

Read next

Case studyVideo and content

Why your tool calls a long job stuck when it is still running

Twice in one week a video platform told a team an ad had stopped while it was still being made. The fix was to ask the step holding the job before calling it lost, instead of deciding from a clock.

5 min read

Case studyVideo and content

Why your AI presenter changes background mid video

A client's video team saw their AI presenter change place halfway through two new ads, and remaking the lines did not help. The cause was a setting that had been switched off in one kind of video only.

4 min read

Case studyVideo and content

Why AI video drops the presenter on lines with prices and decimals

A client's video team found good presenter lines replaced by stock footage whenever the script held a decimal. The automatic check was reading one number as two, and the captions lost the decimal mark. We traced it and fixed it within a day.

4 min read

We count visits to this blog with our own analytics, never Google's, and share what you read with nobody. May we remember this browser with a cookie? See the privacy policy.