Radio as an industry attracts “interesting” people, and I have the “pleasure” of working with them. The station personnel I work with are usually normal people, but every once in awhile you’ll run into a real wingnut. I’ve found King Wingnut.
Yesterday, I assisted in a training conference call for a radio market I’ll be converting in a few months. I was there just to answer questions the trainer couldn’t handle (because this particular trainer can’t handle ANY), and I closed the call by inviting them to “Call or email me if you have any questions.”
King Wingnut took it to heart. This is the email he sent me that afternoon:
Let me introduce myself and present a few credentials. Yes, I am bragging. Deal with it! :-)
I have more than 30 years experience doing radio traffic, and have gone through many traffic system conversions in that time. I must say that I am more confident about the (Your Software) change than I have been with any other. It is very apparent to me that the sweeping changes we are going through are being driven from the top down by people who understand the broadcasting business, and have a clear vision not only of where they want to take Corporate Overlord, but exactly now they are going to get there. And best of all, they have the drive and the talent to make sure it happens.
I won’t say I am good at traffic. I am damn good at traffic. I have experience in both computerized and non-computerized traffic systems. In my first traffic job back in 1970 I had to create a system from scratch and it served the single AM station I worked at for six years.
My first computerized system was from a company called XXX later renamed to YYY. This was in 1976, and it ran on a mini-computer that cost over $70,000 and was so unreliable that it required a maintenance contract that cost us more than $800 a month to keep it’s mighty 5 MB hard drive system (the size of a small file cabinet) running.
Next came the upgraded ZZZ system that actually assembled the logs from an orderfile rather than requiring manual placement of new orders. This came about when a new station in town wanted my ZZZ expertise (ZZZ was the only game in town in 1981) and nearly doubled my salary to get me. :-) We drove ZZZ crazy — we got our hands on an uncompiler and decompiled their software, fixed the bugs in it, recompiled it, and sent our bug fixes to ZZZ! Eventually we decided we could write better software (“We” being myself and the chief engineer, a computer genius who went on to a good career in IT management) and wrote our first traffic system in one [very long] night when the mini-computer broke once again. It was a very crude system mimicking the first XXX system I ever used — but it got logs done for us for about a week while we got rid of the mini-computer and went to a Unix based PC system, and wrote a real traffic system in the C programming language, built around an Informix database system.
For our usage, it was the best traffic system I ever saw — better than YYY, better than ZZZ, better than (Your Software’s competitor), better than (Your Software). Imagine how lean and clean (Your Software) could be if it only had to work on one single radio station in the whole world, with only one kind of break structure, one kind of programming, one kind of automation system, etc. Our system was so tight and integrated to our requirements that it would have been completely useless in any other environment than ours. There was no flexibility of any kind built into it because we didn’t need any flexibility.
It was a hard changeover when Company RevA (which subsequently became Company RevB and then Company RevC and then Corporate Overlord) bought the station I was at (I was actually one of 6 partners that owned the station) and I had to go to (Your Software’s competitor) traffic software. It was different from what I was used to, so it couldn’t possibly be any good. :-) Over the years I came to appreciate what it could do and its flexibility was impressive. Then, when (Your Software’s competitor) upgraded to their next version, I became a true believer. The cart rotation system was (and still is) so much better than the system that I co-authored. I would never have thought of the concept of the two-tiered rotation system (plan level, and within the plan level, the cart level) much less been able to block out the coding for it. Without exaggeration, I can challenge you to come up with a cart rotation scheme that it cannot handle easily and gracefully, and predict that you cannot. If you wanted 5 carts in a percentage rotation, with two of the carts to run 50% each on Thursdays only but with a 5pm cutoff, and all carts to rotate by percentage in all other days/times — it would be trivial to do so.
I became enough of a power user in (Your Software’s competitor) that they put me on their beta test team, and they told me that I found more bugs and made more suggestions that subsequently found their way into release software than all the rest of the alpha testers combined. I am the only person in the history of (Your Software’s competitor) to ever defeat their “magical shift-F9 code”. (Your Software’s competitor) has hidden menus that are to be accessed only under the tutelage of their tech support. Menus that if used injudiciously could damage or destroy your data files. These menus are used to clear error flags and restore indexes, or maybe “unpost” traffic data that was erroneously sent to A/R. To access these menus, you call (Your Software’s competitor) tech support, they direct you to the appropriate menu where you have to key in “Shift-F9” which generates a query number. You tell (Your Software’s competitor) the number, they give you a reply number to key in, and that unlocks the hidden menu. I kept track of the queries and replies for a couple of years (yes, years!) and reverse-engineered the algorithm they were using to generate the counter numbers. (Actually, it turned out my algorithm was easier to use than theirs, and a lot of their techies are using my method now instead of the “official” one which requires use of a calculator. Mine does not.) It caused a small panic at (Your Software’s competitor) the first time I ran Shift-F9 to get my query number, and came up with the reply faster than the tech support guy could give it to me.
I abandoned my beta tester status with (Your Software’s competitor) when they brought out Version IV, which had a “true GUI interface”. I refused to upgrade my system to that software version, because it would have required me to spend about 25% more time doing traffic than with the old system. It was a true GUI interface only on the very surface. (Your Software’s competitor), as you probably know, is an entirely menu-driven system. The only time a mouse is used is to click on the desktop icon to start the program. After that, it’s all keyboard. ” Eeeewwww! Old DOS-style technology.” It just happens to be hugely more time-efficient than click and drag for most operations that are required in traffic. When (Your Software’s competitor) added their GUI interface, the only thing they did was to make each menu item selectable by clicking with a mouse, but they also kept the old system of being able to type the menu item number. Which do you think is easier? Typing in the number “3”, or taking your hand off the keyboard, finding the mouse, dragging the mouse cursor over so it is on top of the “3”, clicking the mouse, then returning your hand to the keyboard? I could have lived with that — except that in a blatant example of pandering to Sales ((Your Software’s competitor)‘s sales department, that is) they made the “Master Menu” (the one you have to go through in order to change from one station to another, or from Traffic to A/R, or Payables or whatever) all pretty and full of clickable mouse icons and no keyboard shortcuts to get through it. “Look at us,” they said. “Now we’re a real Windows program just like Microsoft Word or Excel. See the pretty icons?” Station managers loved it — because they didn’t actually have to use the software. (Your Software’s competitor) salesmen loved it because they could sell it to clueless station managers. For me, it was disastrous. Here’s why…
I do traffic for four stations, usually 100% sold out stations. (More about that later) In (Your Software’s competitor) (but, apparently, not (Your Software)) each station’s software, data files, configuration, etc. is separate from the others. Basically, I have four standalone systems, loosely connected through the Master Menu. This means when I have an order that runs across more than one station, I enter it into the first station, then copy that order to the (Your Software’s competitor) clipboard (not to be confused with the general Windows clipboard) then go through the Master Menu to the next station, and then paste that order from the (Your Software’s competitor) clipboard and make whatever changes are required to accommodate the new station, usually just the spot rate. It sounds cumbersome, but I can copy an order, paste it to two other stations and adjust the rate for each of those stations in about one quarter the time that it took you to read this paragraph.
How can I do that? Because I use a programmable keyboard. Once I have an order entered in one station, I type the letter “C” to copy it to the clipboard, then hit one of my programmed keys which closes out the order, takes me down to the Master Menu, goes to the station where I want to copy the order, where I key in “+” (to signify new order) and “P” to paste the order from the clipboard. So I’ve closed out one station, opened the next station, pasted the order into the new station, all with a total of 4 keystrokes. You couldn’t even get your hand off your keyboard and onto your mouse in the time it takes me to do that. All is well and good — until my keyboard macro program self destructs when it can’t get through Version IV’s Master Menu because it requires a mouse to do so. That’s why I am still using Version III, and my biggest concern about (Your Software) is that I am going to run into the same sort of problem!
If I understood today’s teaching conference correctly, you personally are going to be coming here for our conversion. Is that correct? I am really looking forward to that — getting to talk to someone who in the short run knows more about a traffic system than I do. Give me a few months to use (Your Software) and I will be your “star” pupil! I think I can show you a few interesting things about traffic in general, and show you some (Your Software’s competitor) ideas that you aren’t familiar with that are well worth plagiarizing. For instance, let me tell you how I deal with sold-out radio stations. Actually, it is kind of pointless for me to describe this, because the spot placement paradigm that (Your Software) uses (booking agent runs all the time, logs assembled 15 months in advance, unplaced spot pool) is completely non-conducive to my (Your Software’s competitor) method. But I’m going to tell you anyway, so you’ll be impressed with how smart I am. :-)
First rule of log assembly: Never assemble a log that isn’t “possible”. When I assemble a log, each daypart is usually sold at 100.0%, usually time but sometimes I run out of units first. This is because my inventory management report is 100.0% accurate. If my time sold report says I am 11 minutes oversold, I absolutely guarantee that if I were to assemble and edit that log, when I was finished I would have exactly 11 minutes worth (maybe 22 :30’s, or 11 :60’s, or more likely a mixture of :30’s and :60’s heavily biased towards :30’s) of unplaced spots. But I don’t assemble a log that way. I give the time sold report and my one-day spot listing (a list of each spot that will make up tomorrow’s log) to the sales manager, and tell him to get rid of 11 minutes worth of commercials. He chooses who gets the axe. Then, I work with the time sold report (it takes about 5 seconds to recompile it) and adjust my BTA parameters to weight certain dayparts more or less heavily) until every daypart shows as being 100.0% sold. Then I assemble my log. When it’s assembled, I’ll typically have three to five spots on the bump list that the scheduler wasn’t smart enough to place (it makes 120 assembly passes and then gives up) and I place them manually, because there is room in the log for them, I made sure of that before I started assembly.
Using this method, we “pre-qualify” our logs a week before we assemble them. We always know exactly the state of our inventory, where we’re over-sold and where we’re undersold. Pretty much what the (Your Software) booking agent does, but with more personalized control. I’m not comfortable with what I perceive as (Your Software)‘s rather cavalier attitude towards BTA spots. 60-70% of our total spot load is what you would call BTA, what I would call TAP, and to me TAP comes with an obligation to give reasonable vertical rotation. Just because an order allows spot placement from 6am-Midnight doesn’t mean that we should run 80% of their spots after 7pm. Oh, that’s great in the short run — you move those supposedly pre-emptible spots out of the way and stick higher-priced dayparted spots in their place. But in the long run, those TAP clients who got screwed are going to go spend their money someplace else, and those TAP clients represent over 50% of our revenue. To me, a schedule that crosses multiple dayparts carries within it an implicit contractual obligation to give more or less even distribution across those dayparts. Perhaps I’m wrong about this, but my impression of (Your Software) is such that I’m surprised that they don’t just use the rate per spot as the sole prioritizing agent and the hell with any long-term concerns about repeat business.
All that said (and congratulations for making it this far through this email!) I am greatly reassured that, aside from the booking agent/pool idea, (Your Software) seems to be very similar conceptually to (Your Software’s competitor). I do not foresee any great difficulties in making the transition.
ps: Do you remember “(Early version of your software)“? That was the precursor to (Your Software). I was one of a group of about 10 traffic managers from all over the country that Company RevC sent down to San Diego about five (?) years ago to act as a “test group” to train their installers. (Early version of your software) was a disaster, and I was the terror of the test group in pointing it out to them. Nonetheless, (Your Software)is built on the bones of (Early version of your software). I just hope that they have greatly improved it since then.
Oh. My. God.
I’m not looking forward to working with this guy for next two months. At all.