Moving forward with SWIFT projects, let's ensure each of these bullet points is understood and agreed to by SyncWords:
- Max file length for 2-hour TAT.
>> 15 minutes. This content is generally pretty difficult and packed with details that require research. Also lots of musical numbers that aren't always easy to research lyrics. A 15-minute file can take 45 mins to an hour to complete, possibly even exponentially longer the longer the file is. Therefore, in order to guarantee instant turnaround, files over 15 mins may take longer than 2 hours or simply be rolled to the next day.
- A description of ‘rolling projects’ (or some other name) – that is, we get chunks of files bit by bit
Rolling Projects: This has been the way most SWIFTS have gone, meaning the files trickle in one by one over the course of the night, sometimes with large gaps in between. The benefit is we dont have a giant pile of work that's all suddenly due in 2 hours. There's time to work on them one by one and this gives the newer files time to load. The problems with this method are that if it drags on too late, we start losing scribes, losing clarity or risk entering into a new pay period if we go past midnight.
- A description of ‘all-at-once projects’ (or some other name) – that is, we get all the files all at once (this we cannot guarantee 2 hour TAT)
All At Once Projects: We've had a few of these where the entire batch arrives at once. The benefit being we can turn the whole project around much sooner. The downside we have very little wiggle room between reception of file and delivery.
- What they need to put in the project name [[[EXPEDITED]
At some point they switched to EXPEDIATED. This triggers the incorrect billing and due date. (it can be manually adjusted but better to have automated)
- What they need to provide us (scripts/names/etc.)
Sometimes the scripts are only vaguely helpful. A lot of the musical content tends to be either new, adlibbed, which there's no shortcuts around. So while it'd be nice to have these guaranteed, I wouldn't call it a dealbreaker if not provided. Providing via email ahead of time would be most helpful.
- Timeline
We should set some parameters as far as how early or late we're willing to let a project go. At what point do we just say goodnight and let the files roll over to the morning? I think midnight seems like a logical cutoff point for projects that are intended to wrap up by 10 or 10:30. If we know ahead of time files should arrive after midnight, perhaps we can accommodate, but we want to eliminate just waiting around in the middle of the night for files to arrive.
- Scribe expectations.
We need to have scribes agree to a set period of time to commit instead of showing up / leaving at their leisure. If they know ahead of time they can only stay for __ amount of hours, we can honor that if we have enough scribes on the roster.