Most writers who submit their work soon learn the importance of keeping detailed records. They find it’s essential to record which manuscript has been sent to which editor at which publisher on what date and with what results. Usually, they keep this information on index cards or log sheets, one for each title.
The shortcoming of this method shows up after you’ve made many submissions of many titles and then need to cross-reference. Yes, you can easily see which publishers have considered a particular manuscript. But it’s not so easy to see which manuscripts have gone to a particular publisher—and the more you submit, the harder it gets.
Of course, you could keep a separate set of records organized by publisher—but that complicates things considerably. And it still doesn’t help in tasks like tracking submissions to a particular editor who has moved through several publishers.
The solution is a computer database. Once your records are in electronic form, you can easily search and sort by title, publisher, editor, or anything else you care about. In fact, you’re sure to think up new questions to ask of your records. For instance, I can quickly tell you that my overall ratio of submissions to acceptances is . . . . Um, never mind.
For my own submissions database, I use FileMaker, which is available for both Mac and PC. Here are the fields I include:
Figure 1. Submissions Database
Title. The title of the work.
Work #. This is a unique identifier for each work—for instance, A73 for this article. The identifier helps me keep track of a work if the title changes. Of course, I use the same identifier—along with title keywords—to label the work’s folders on my computer and in my paper files.
Work type. The genre—picture book, easy reader, chapter/novel, nonfiction, or collection for book‑type submissions; story, script, article, or poem for others. I select my choice from a pop‑up list.
Submission #. A unique serial number for each database record, entered automatically by the program. This number helps me track the submission between this database and a related one for sales.
Form. The kind of material submitted—manuscript, query, proposal, or previously published book—all in a pop‑up list.
Version. I put a version number on each of my manuscript and proposal drafts, numbering them like computer programs—1.0, 1.1, 2.0, and so on. Noting the version number in a submission record then lets me know exactly what I’ve sent. (My agent, though, tells me not to print the number on submission copies themselves.)
Market type. Book, periodical, anthology, theater, film/TV, Web, miscellaneous—all in a pop‑up list.
Market age. Adult or kid, selected by radio buttons.
Date sent. The date in a sortable format.
Submitter. Either me, my agent, or both combined, in a pop‑up list. (Though my agent handles submissions of most new book manuscripts, I commonly submit older ones, magazine stories, articles, and so on. I also keep records of her submissions so I can track my stories and make suggestions.)
Resubmit? A check box to tell if this is a repeat submission of this title to this editor and publisher.
Publisher. The one sent to. For a periodical, this is the publication name.
Parent. If the publisher is an imprint, I put here the publishing house it’s part of. For a magazine, I put the magazine group—for instance, Cricket, for Cricket magazine and all its sister mags. A pop‑up list provides names I use often.
Editor to. The editor addressed, if any.
Rights offered. Book, First Serial, Reprint, and so on, in a pop‑up list.
Exclusive? A check box showing whether this is an exclusive submission.
Until. A cut‑off date for exclusive consideration. (This date would be given to the editor on submission only. Generally, there is then no need to give later notice or to withdraw the manuscript before sending it elsewhere.)
Reply date. In a sortable format. I can quickly tell which submissions are still out by searching for “blanks” in this field.
Editor from. The editor replying, if a name is given. (This may not be the editor submitted to.)
Response. This pop‑up list has all possible responses: accept, reject, conditional (on successful revision); lost, returned, withdrawn, replaced (by a later manuscript version); none, unknown; and—for queries and proposals—invite, decline, and postpone.
Notes. Explanations, editor comments, or anything else.
Sold? A checkbox for quick sorting and to tell me there’s sales info in a related database.
To let you search and sort your records, you need to standardize how you enter much of your information. For instance, you don’t want to use different forms of a publisher’s name—like both “S&S” and “Simon & Schuster.” You must also watch your spelling, as a single mistake can make a record invisible to a search.
These are the reasons I make liberal use of pop‑up lists, radio buttons, and check boxes. (Pop‑up lists—as opposed to pop‑up menus—also let you type in text directly if none of the choices apply, or if more than one does.) If the program you’re using doesn’t offer such features, you might keep a “style sheet” handy, showing each common entry in the form you’ve settled on.
Also vital for any database: MAKE SURE YOU HAVE BACKUPS! Years of records could be corrupted or lost in a split second, so don’t take chances. You should have a series of dated copies, with at least some away from your computer, and at least one away from your home.
Of course, once you start with databases, you’re not likely to stop with recording just submissions. For instance, I use two separate databases to record sales. The book sales database has details of book contracts, such as which rights I’ve reserved. The story and article sales database holds info on magazine and similar fee‑based sales, including whether I’ve been paid.
Figure 2. Book Sales Database
Figure 3. Story and Article Sales Database
As you’d expect, I’ve also replaced my index‑card address files with fully searchable and sortable data on all my professional contacts. In fact, I have eight contact databases, with different sets of fields for different contact types! My publisher and periodical databases, for example, have pop‑up lists for an individual’s job type—editorial, production, and so on. The periodical database also has room for two mailing addresses—one for manuscripts and general business, another for sending books for review. This lets me easily print out reviewer mailing labels to send to my publishers as my books come out.
Figure 4. Publisher Database
Figure 5. Periodical Database
My favorite trick in a contact database is to set up separate fields for name, city, state, zip, and country, but add an extra field for the entire mailing address in one piece. (You can do this only if your program allows line breaks within fields.) This makes for some double typing, but it lets me just as easily copy or print an address as sort on it. It also lets me put last name first in the name field, making it possible to sort by an individual’s name, while I can still print it in normal order on envelopes and labels.
Maintaining a set of databases takes a significant commitment of time and effort. Like the computer in general, it doesn’t save you work, but it does help you organize your work more efficiently and accomplish more. So, if you’re overwhelmed by a mass of index cards, or tired of searching for crucial bits of paper, databases may be just what you need.
