the payment and receipt of food is still done serially, which would seem to negate any benefit from orders being placed in parallel.
There is no reason to assume this is true.
The answer, from a UX perspective has to be:
The benefit for the user is getting their food faster because the restaurant can process more meals per hour, leading to shorter queues.
There are two things to consider here to understand why the basic premise of this question is probably wrong.
Simply moving from a concurrent step to a serial step does NOT negate the benefits of the earlier paralellism.
Let's look at an analogous example from web development. We want to fetch data from two different servers (parallel processes) and then use that data to render text into a web page from top to bottom (serial process).
If it takes 3 seconds to hit each server and 1ms to render the response from a server we can obviously either take 6 seconds or 3 seconds to finish the task depending on our choice of parallel or serial for the first step ONLY.
The second step's parallelism changes the overall situation by 1ms, making it completely irrelevant.
You see the same situation at the fast food restaurant.
Time to take an order, create and package the food ~= 5 minutes.
Time to take money and hand food through a window ~= 30 seconds.
Provided that the internal team has the facilities to prepare at least 2 orders at once, the result is:
Step 1 in parallel = 5.5 minutes total
Step 1 in serial = 10.5 minutes in total
The parallelism of step 2 doesn't negate anything here.
A system with a series of sequential steps is constrained ONLY by the slowest step.
This is called theory of constraints. It has a wikipedia article too.
The summary is that in a system with a chain (or even multiple converging or diverging chains) of processes that need to be completed, the system moves only as quickly as the slowest step.
Attempts to optimise any step other than the slowest step have no positive impact and can even have a negative impact on overall productivity.
Imagine a traffic jam at peak hour where many lanes (A) converge into fewer lanes (B) and then diverge back to many (C). Something like this:
It should be clear that adding additional lanes at:
A - will make traffic worse by increasing congestion ahead of the bottleneck (incidentally, this is why we use words like "bottleneck" to talk about a limiting factor in a process)
B - will increase throughput of the system
C - will have no positive or negative impact on the traffic
Your example of a fast food restaurant (or literally any other system in the world) has just one severely limiting factor at any point in time. Nothing else is worth optimising.
Think of the following stages of throughput in real space/time terms of burgers per minute per square meter, after all, this is how they pay rent (I'm just guessing rough numbers):
- Collecting orders (~ 2 mins) from a drive thru lane (~20 m2) = 0.025 b/min/m2
- Preparing orders (~ 3 mins) from a burger grill (~1 m2) = 0.3 b/min/m2
- Delivering orders (~ 0.5 min) from a kiosk (~2 m2) = 1 b/min/m2
Now also consider that the nothing can be done before you place the order yet preparing and delivering orders can be done in parallel with taking new orders.
It should be clear why:
- A very large amount of physical space shown in the OPs aerial photo is dedicated to taking orders, relative to other tasks
- Taking orders is handled in parallel (it is the step that needs to be optimised)
- Every other step (before and after) can be safely handled in serial (trading throughput/latency for less physical space requirements) as their throughput does not effect the throughput of the system overall
It also hints as to why perhaps having 2 lanes for orders makes sense but not 3, or 10 or 50 - this would be out of proportion for the size of the kitchen and other available facilities required to process burgers.
One potential avenue for followup, would be whether this restaurant is really optimised for consistent user experience (latency) or just total revenue per square meter (throughput). As far as sending items concurrently through parallel/sequential processes goes, they are not necessarily the same thing. It's quite possible to optimise overall throughput in such a way that individual items may suffer additional latency (like when the OPs order is forgotten at the kiosk).