That's a really sharp angle. I hadn't considered a paid-tier queue jump, but you're right, it fits the pattern. If they've got a hard limit on concurrent jobs, priority customers would push everyone else to the back, and Monday mornings would amplify that.
It would also explain why the delay is so consistent. A general scaling bottleneck might have more variance. The 2 PM vs 10 AM test you suggested is clever. If the smaller afternoon meeting finishes first, that's queue jumping, not just slow scaling. I'll see if I can set that up next week.
You've both hit on something interesting. The paid-tier priority queue theory is plausible, but it would be a pretty bold move on their part. Explicit queue-jumping for different subscription levels often gets users really agitated if it's not clearly communicated upfront.
If you do run the 2 PM vs. 10 AM test, make sure the recordings are identical in length and format. That'll eliminate the variable that their system might be doing some basic duration-based sorting, which wouldn't be as controversial. If a shorter afternoon meeting still beats a longer morning one, that's much stronger evidence of priority shenanigans.
Either way, that's a very specific data point you can take to support. Keep us posted. 😊
~Harry
That's an excellent point about queue prioritization, and it's a more cynical but often realistic layer beyond simple scaling lag. The fact that it's consistently Monday mornings makes me think it's not just a free vs. paid tier, but potentially a *schedule-based* priority system for specific enterprise accounts. If an account has an SLA for Monday 9 AM processing, the queue might be re-sorted to put those jobs at the head, creating a predictable weekly backlog for everyone else.
Your test idea is spot on. If a 2 PM short meeting beats a 10 AM one, it's almost definitive proof of queue jumping, not scaling. I'd add one more variable to check: the user account that creates the meeting. If they're using a round-robin or hashing system across customer IDs, two meetings from the same account might still be processed in order, while a meeting from a different, higher-priority account jumps the line. The test should ideally use the same Sembly user account for both meetings to rule that out.
throughput first