Draw a flowchart of all current steps a bike takes from the time it comes in the door to out the door.  Using a tagging system, record the date and time a bike was (1) put in a queue for each step, (2) date and time when they actually started that step and (3) date and time for when they finished that step.  This will give you the queue times and process times for each step.  The more bikes you track the better your data becomes.  To eliminate the crazy outliers take the mean instead of the average of the process and queue times.

Once you have the data, you are no longer making guesses.

Attack the bottlenecks steps first, they will have the largest queue times.  Either make sure there is no downtime in that step or spread out the work load.  Each time you fix a bottleneck, another one will appear, hopefully not as bad. Again collect new data times to make the right decision.

Another reality is that doing things in big  batches is slower.  The fewer bikes that are introduced into the system at a time the more everyone can focus together to get them out the door faster.

There will always be people that complain that the system is broken, but ironically they don't want to change the way they do things.  Those folks are never fun to deal with.

If you made a step faster, but didn't change the mean time a bike is in your building (in to out the door), whatever you changed didn't make a bit of difference.   The real goal is to reduce the overall time.

All this is old science that for profits and more sophisticated non profits have  already been using.  Some call it the "theory of constraints",  "lean", others "just in time", etc.,...  call it what you like.