As a publisher of any size there is a large number of tasks required to get a book from initial conception through to publication, and the challenges increase with the number of books you’re managing, the number of staff and departments, and the variety of products.

The date by which these tasks must be completed is often related to the publication date of the products being produced. For example, a task to “confirm the product prices” might be required to be completed by three months before the publication date.

The to-dos functionality helps your organisation manage these tasks by providing ways to list all of the tasks to be performed in production of a book, to assign the tasks to a user who has responsibility for either doing the task or for making sure that a third party has done them (e.g. to check that a printer has shipped the products), to see all or some of the tasks on external calendar systems such as Outlook or iCalendar, and for tracking whether and when the tasks have been completed.


A to-do is always associated with a work, and each work has its own page on which the to-dos are listed. This is generally the best place from which to create new tasks, as you can also see the other tasks specifically for that work.

There are three elements of a to-do

“What needs to get done?”

Enter a description of the task that needs to be done.

It might be tempting to phrase these in terms of a task that should be completed by a third-party, such as Print books. However unless the person to whom the task is going to be assigned is going to be actually doing the task (Finalise subject coding), phrase it according to the task that will actually be done by the assignee:

  • Send files to printer
  • Check printer proofs
  • Confirm job with printer
  • Check printer has shipped products

Because to-dos do not have a duration, use multiple to-dos to indicate the events that mark the beginning and end of tasks. For example if a proof-reading is expected to take five days, use two to-dos “Start proof-reading“ and “End proof-reading“ five days apart. This also allows you to show progress by completing the “Start” event Because each to-do is associated with a work there is no need to mention the name of the work in the to-do description

“Who is responsible?”

The person responsible must be a user of the system, as they will be the person who checks the activity off when it is complete.


There are three options for specifying a date.

Firstly, you can leave the task without a due date. Avoid this if possible, as undated to-dos will not be listed on external calendaring systems, and if there is no date by which it is due then you have to womder whether it is worth doing at all.

Secondly, you can specify a fixed date. This might be most appropriate where the urgency is dependant on an external factor, such as the need to send metadata to a sales agency by a particular date that they have dictated.

Thirdly, you can specify a relative due date. This lets you say that a task is due some time before, or possibly after, some event associated with the work such as a publication date. Quite a few of these “base dates” will be listed in the drop down, such as:

  • “Earliest pub date” – the earliest date on which a product is expected to be published
  • “Latest eBook pub date” – the latest date on which any ebook product is expected to be published
  • “MS delivery date” – the manuscript delivery date on the contract

These should be self-explanatory, although it is likely that some of these will have no date value showing – you may not be currently planning on a PDF ebook for example.

By selecting one of these base dates and entering a number of months and/or days, you are specifying the date by which the to-do task should be completed.

For example, if you know that the products should be at your distributor one month before the publication date you can specify a task for Check delivery to US Warehouse as Due 1 months and 0 days before earliest print pub date. If the earliest print pub date changes at any point in the future, due to delays in the manuscript delivery for example, the due date for this to-do will automatically change.

Positive numbers are treated as “before” and negative numbers as “after”, so you can create a to-do “Conduct anniversary performance review” with “-12” months, which will be twelve months after the publication date.

You can mix positive and negative numbers, so “2 months and -1 days” means “one day after two months before …”, and “-12 months and 5 days” means “five days before the first anniversary”.

If you select a base date that has no value, such as “Earliest audiobook pub date” on a work for which there is no audiobook planned, the due date for the to-do will always be blank until that base date has a value.


The due dates of the to-dos in Consonance are often going to be estimated well in advance, and could clash with other dates that are not expected to be stored in the system such as staff vacations, public holidays (in countries where key suppliers such as printers operate as well as your own), or industry events that you’ll be attending.

It might also be helpful to be able easily to identify situations where completing a task a little early or late may be beneficial. For example, if you are meeting with an author on Wednesday it may be helpful to push back a briefing with a cover designer until the day after, or advance a Check with author on peer review feedback to a few days before.

Furthermore, because of the natural bunching up of publication dates that many publishers have, you may find that the due dates of similar tasks across multiple works naturally coincide with each other, and you may want to tackle several related tasks together.

To help identify, and either avoid or take advantage of these situations, the due dates of to-dos can be made available to external calendaring systems such as MS Outlook, iCalendar, Google Calendars, Lotus Notes, etc., where they can be viewed alongside all of the publishers other commitments. These calendaring systems might be installed on your computer, such as for iCalendar, or be a web-based system such as Google Calendars.

This is called “subscribing to a calendar”, and the technology is described in more detail in this article.

Two types of to-do calendar subscription are available:

  • A full client subscription, in which the calendar system will see all incomplete to-dos for the entire client account.
  • A user subscription, in which the calendar system will see all incomplete to-dos assigned to a particular user of the system.

You can access your own user calendar subscription URL from your dashboard, on the to-dos panel, or the full client subscription URL from the to-dos page accessed under “Workflow” on the main menu.

You can also subcribe to other users’ calendars by getting their own URL from the Users page – by adding multiple users’ calendars into your system you can use the calendar system controls to show them in different colours and to temporarily hide them.