The fundamentals of scorekeeping are the same for all tournaments, from PPTQs to GPs.

When judging, the Comprehensive Rules don’t change between different event types, and there are only two different systems of resolving any given judge call. (based on the REL) There are structural differences at larger events, with judges specializing in specific roles and responsibilties, but the core of the judge call is fundamentally the same at every event.

The first time that I scorekept a GP through the Top 8, I asked about anything special post-event that needed to be taken care of for a GP from a scorekeeping standpoint, and was somewhat surprised to find out that there wasn’t really anything. The first third of the tournament was full of situations that are very rare at smaller events, and the preparation for the tournament was at a level you realistically never need to do at a store-level, but as the tournament progressed, it was really about the same as any other tournament. Just, you know, larger.

Even at PPTQs and small tournaments, you can learn and refine the primary base of skills that you would want to have at a larger tournament: entering in players, slips, and penalties. Discovering and understanding the exact processes and quirks of each will allow you to be flexible, as you move to larger tournaments and begin to balance speed and efficiency into the equation.

Most differences between events come at the periphery.

As you work your way to larger scorekeeping gigs, you will not experience many differences with the event mechanics themselves, but instead you will begin to have new challenges along the peripheries of a tournament. You’ll start having tournaments with preregistrations, and with that comes incorrectly-recorded DCI numbers without the player nearby for a quick fix. You’ll occasionally be responsible for typing up decklists for a tournament, and will develop a workflow to minimize typos. You may need to start managing side events to a larger event day, and figure out how to balance a 200-player main event near time-in-round, with registrations for a 40-player side event starting immediately after the main event turns over it’s next round, while also firing an 8-player pod.

The core of a tournament’s processes will not really change, but having a strong base of knowledge in the tournament will allow you to continue to manage events, while expanding your knowledgebase and experience into these new aspects that will be thrown at you, sometimes without your knowledge. Overall, your best tool for advancing is flexibility and preparation – recognizing when new elements present themselves in a tournament, and working to fill them effectively.

The tournament in software only needs to match reality when it is reported.

The easiest way to look at this is by looking at the critical path of the tournament, and what needs absolutely needs to be done on that critical path. For a tournament, that is the continuing march of new rounds being paired, processed, and turned over. The key part in there is the turn-over and pairing, which requires a few things to be true:

  • All players relevant to the event are in the correct status, i.e. they are either enrolled (will be paired in the next round) or dropped. (will not be paired)
  • All match results need to be reported as accurately as possible.

Realistically, that’s it. A penalty won’t break anything if it’s entered in two rounds later. A mis-typed name or DCI number won’t break anything if it takes three rounds to get around to.

If you have a larger issue, you may need to look at the options for fixing it, and balancing their costs on the pace of the tournament. If you think of a theoretical issue where a match result slip is incorrect, but a bug is preventing the result from being changed, then you may need to balance the time costs of fixing things by-hand each round, versus recreating the event, versus other options.

You can also look at this in the opposite way, with some tasks that you may be asked to do, and figuring out where you can frontload work. For instance, at some events, you may be asked to help digitize top decklists as part of the data being sent to the organization behind the event. This process could begin as early the second-to-last round in many tournaments, and can usually be mostly-complete before the Top 8 is announced.

The scorekeeper is the person at an event with the greatest influence over the speed of the tournament.

At a normal, large tournament, the most visible slowdown will be the final table playing at the end of a round. They likely have a time extension, and time will be called in their match 10-15 minutes after the main clock reaches 0:00.

Behind-the-scenes, however, the scorekeeper can have an underlying impact in more subtle ways. If you have an eight round tournament, and each round takes 2-3 minutes to turn around, then the scorekeeper is responsible for ~20 minutes of downtime throughout the tournament.

Reducing the scorekeeper downtime often involves workflow optimization, and ordering processes to maximize the amount of information you can release from the software at a time. Even at a small event, this process can be practiced by prioritizing, front-loading work, and working efficiently:

  • When the last slip comes in with a penalty, you can enter in the penalty after the next round has started. (drops, not so much)
  • When you are printing and posting pairings, are you already prepared to post those pairings? Do you have torn tape ready for the pages? Are last round’s pairings taken down? Do you have additional space ready for the round that you begin to also have standings to post?
  • Are you spending time navigating menus to print match result slips, when pairings are already printed and sitting on the printer?

At larger events, you can start looking at other efficiencies. One of the major ones is in interspersing large print jobs with navigating digital needs, so that you can take care of high-priority things for different groups while things are queued. For example, let’s look at my GP workflow when waiting for the last couple slips:

  1. Have two emails ready to send: one to the on-site coverage producer, the other to the online coverage producer.
  2. Backup the tournament.
  3. Enter in the final 2-3 results, as they become available.
  4. Turn over to the next round.
  5. Backup the tournament.
  6. Print pairings by player. In the downtime waiting for the print option to generate, run the file conversion process on the backup to get the online pairings file.
  7. Export pairings by table in two separate formats, once for on-site coverage, once for online coverage.
  8. Move to browser and send the pairings by table to on-site coverage producer.
  9. Change tabs and begin uploading the online pairings file. (it takes about 30 seconds to upload and populate the database)
  10. Move back to WLTR and print random random tables + match result slips. (this should be done quickly enough that the pairings should still be getting printed)
  11. Export results and standings for the previous round for online coverage.
  12. Deal with any on-site issues. (incorrect results, mis-drops, etc.)
  13. Send exports to online coverage producer.

There are a few very small efficiency gains in this process. The end-of-round backup is done before the last result, because a restore isn’t fundamentally-different between zero slips outstanding and two, but there is a difference between the two on whether or not the scorekeeper is in the critical path. Similarly, operations are done in an order that simultaneously keeps the printer busy, keeps judges moving through their round turnover processes, and keeps me moving through WLTR efficiently. (the major slowdown being if I would need to keep opening/closing the printing/reporting subsystem, which is is why the one load is paired with a non-WLTR operation that also takes a few seconds)

My internal goal is to be responsible for no more than 30 seconds of downtime combined in a round,  and 60 seconds at GPs.That’s 30 seconds between the last match finishing (not the last slip coming up) and the first printout starting in the printer.

Occasionally, you’ll also have to deal with larger issues, where you will be  balancing the costs of various solutions against the pace of the tournament. If you think of a theoretical issue where a match result slip is incorrect, but a bug is preventing the result from being changed, then you may need to balance the time costs of fixing things by-hand each round, versus recreating the event, versus other options.

More often than not, these days, the skill of scorekeeping comes down to accuracy, organization, and prioritization, more than simply speed.

I’ll refer directly to Nick Fang’s blog on Anticipation on this one, as it identifies a skill that I’ve worked consciously on in the last couple years, and took some refinement on my part to get right. Scorekeeping at an advanced level requires knowledge of not only what you need to do to have a successful tournament, but also what others need from you.