Product
Work and calendar
Work that is not attached to a record is work no one else can pick up, which is the entire problem with keeping it in a personal list.
Work that lives in heads
Every organisation runs on promises no one wrote down
The work in a small organisation is mostly commitments made in conversation. Ring them back on Thursday. Send the quotation once the survey is in. Check whether they went ahead. Chase the certificate before the deadline. Each of those is real work with a real deadline, and in most organisations each lives in the head of whoever made the promise, supported by a notebook, a wall planner and a series of increasingly urgent reminders someone sets for themselves.
That works, in the sense that most of it gets done, right up to the moment someone is away. Then the business discovers what it actually knew: nothing. Nobody can say what was promised, to whom, or by when. The customer rings, and the answer is a guess and a promise to ring back.
This is not a diligence problem and it does not get fixed by asking people to be more organised. It is a structural consequence of work living with people rather than with the records the work is about.
Attaching work to the thing it concerns
A task in Consonas sits against a record: the customer it is for, the opportunity it advances, the matter it resolves. That single decision changes what happens when someone is away, because the work is visible where anybody covering would naturally look, which is the customer.
It also changes what the customer record means. A record with the outstanding work on it is a live account of a relationship instead of a filing cabinet, and the question of what is happening with someone has an answer that does not require a person.
And a single view of what is due
The other half is the daily view: one screen showing what is due and what has already slipped, for you and for anybody whose work you are responsible for. It is the first thing most people open and it is the reason the rest of the discipline holds, because a task recorded somewhere no one looks is not much better than a task nobody recorded.
When somebody is away
Six ordinary situations
All six happen in a normal month in a small organisation.
| The situation | Work in a personal list | Work against the record |
|---|---|---|
| Somebody is off sick | No one knows what was promised or what is due. The week goes badly and the customer notices. | Their work is visible against the records it concerns. Whoever covers can see what is due and to whom. |
| A customer asks what is happening | Whoever handled it knows. If they are away, the answer is a guess or a promise to ring back. | The record shows what is outstanding, what was done and when, without asking anybody. |
| A promise made on the telephone | It exists in someone's memory until they write it down, which is sometimes. | A task against the record, due on a date, visible to the person who will have to do it. |
| Recurring work, such as an annual service | A wall planner or a spreadsheet, checked when someone remembers. | A task with a date, in the daily view before it falls due rather than after. |
| Two appointments at the same time | Discovered on the morning, by the customer who was double booked. | Reported at the point of booking, with the choice left to the person who knows the context. |
| A four hour target given at four on Friday | Breached by Monday morning, when nobody was ever going to be working. | Counted in working hours. Due Monday morning, which is what everyone meant. |
Tasks
Assigned to a person, against a record, due on a date
Three properties, all of them required. A task with no owner is a task no one will do. A task with no record is invisible to whoever covers. A task with no date is a wish.
The owner is deliberately a person rather than a team. Assigning work to a team feels collaborative and produces the single most reliable way to lose it, because everyone assumes someone else has picked it up. Reassigning takes two seconds and being wrong about who owns it is a much smaller problem than no one owning it.
Completion is recorded with who and when, and it appears on the timeline of the record it was against. That is what makes the customer history an account of what was actually done instead of a list of things that were said.
The calendar
Clashes reported, because the person booking knows more than the calendar
Appointments sit against the people and records they concern, so the calendar and the customer history are one history. Who came in, when, about what, and what happened.
When two appointments overlap, the product says so and lets the person decide. It does not refuse. The first one may be provisional. They may be at the same address. One may be a telephone call that can happen while driving to the other. A system that refuses does not prevent the double booking, it prevents the booking being recorded, and within a month there is a paper diary again holding the real schedule.
Durations and targets are counted in working hours. A four hour target given at four on a Friday is due at eleven on Monday, not at eight on Saturday. Elapsed time targets punish an organisation for not working weekends, and the effect is that everyone quietly stops believing any target the system reports.
Outside
A booking page against real availability
On Standard and above, a link someone outside your organisation can use to book time. It offers availability from the same calendar your colleagues are already watching, so an accepted time is a time that genuinely exists.
The booking creates the appointment against the relationship, so it appears in the customer history like any other. There is no separate booking system holding a parallel account of the week.
It is deliberately simple. There is no round robin across a team, no routing by questionnaire, no payment at the point of booking. If scheduling at that level of sophistication is central to your business, a specialist tool will serve you better and we would rather say so.
The moving parts
Tasks and appointments, against the thing they are about
What each part holds, and why it is shaped that way.
- Tasks
- Against a relationship, an opportunity or a matter, chosen by searching for it. Assigned to a person, with a due date given as a date or as a number of working days, and visible to anybody who would have to pick them up.
- The daily view
- One screen of what is due and what has already slipped, for you and for anybody whose work you are responsible for. It is the first thing most people open and the reason the rest gets used.
- Appointments
- With the people and the record they concern, so the calendar and the customer history are the same history instead of two accounts of the same week.
- Clash reporting
- A clash is reported rather than prevented. The person booking usually knows something the calendar does not, and a system that refuses teaches people to book somewhere else.
- Working hours
- Durations and targets are counted in working hours rather than elapsed ones, so a Friday afternoon commitment with a four hour target is due on Monday morning rather than breached over a weekend.
- Booking page
- On Standard and above, priced beside sequences, a link someone outside can use to book time against real availability, writing into the same calendar your colleagues already watch.
- Ownership
- Every task has one person responsible. A task assigned to a team is a task nobody has, which is the most reliable way to lose work in an organisation of any size.
- Completion
- Recorded with who and when, and it appears on the timeline of the record the task was against, so the history of a customer includes what was actually done for them.
A system that refuses to make a booking does not prevent the double booking. It prevents the booking being recorded, and the diary on the wall comes back within a month.
Which is why a clash is reported rather than prevented, and why the choice is left with the person who has the context.
Four disciplines
Making the daily view worth opening
Everything with a date goes in, or nothing does
A daily view that contains most of somebody's work is worse than useless, because they still need their notebook and now they have two places to check. The discipline that makes it work is that anything with a date goes in, including the small things, and the notebook goes away.
This is genuinely the hardest part and it takes about a fortnight. The signal that it has worked is someone asking a colleague to add something to their list instead of telling them about it.
Due dates should be when you will do it
Not when it is theoretically required. A task due on the day the customer asked for it is a task that is late by the time anybody sees it. Dating work for when you actually intend to do it makes the daily view a plan instead of a running tally of failure, and a view that is mostly overdue gets ignored within a week.
Overdue should be rare enough to mean something
If everything is overdue, nothing is. The useful state is a small number of overdue items that genuinely need attention, which requires being willing to move dates rather than letting things sit. Moving a date is a decision. Leaving it is a decision too, and a worse one.
Recurring work is where most of the value is
For a business with annual services, six month reviews or seasonal work, the highest return use of this is putting the next one in as soon as the last one is done. That is a habit instead of a feature, and it converts work you would have remembered sometimes into work you do every time.
When the list lies
Six ways a task list stops being true
Each is common, each is recognisable from the list itself, and none of them is solved by asking people to be more organised.
Everything is due today
The symptom is a daily view with forty items on it, most of which are not going to happen. The cause is dating tasks for when you would like them done rather than for when they must be done, which is a small dishonesty repeated until the list is fiction.
The fix is to date for the deadline and let the daily view be short enough to be credible. A list of six things you will actually do is a working document. A list of forty is a wall you learn to walk past.
Someone keeps a second list
The symptom is a person whose tasks are always complete and who is nevertheless always busy. The cause is a private list that is the real one, and the shared system that is the reporting one.
This is almost always a signal rather than a discipline problem. Ask what the private list does that the shared one does not. The answer is usually that it holds things too small or too uncertain to feel worth recording, which means the threshold for recording is set too high somewhere in the culture rather than in the software.
Tasks have no owner, or everyone owns them
The symptom is a category of work that is always slightly late and that no one feels responsible for. The cause is a task assigned to a team, a shared address, or no one at all.
A task with one name against it gets done. The same task with three names against it is done by whoever is most anxious, which is not a system, it is a personality.
The overdue list is never emptied
The symptom is two hundred overdue items that everyone has agreed to ignore. The cause is that nothing is ever cancelled, only deferred, until the overdue count is so large it carries no information.
The fix is that cancelling is allowed. A task that no longer needs doing should be closed rather than pushed, and pushing the same task four times is the signal to ask whether it was ever real.
Appointments live somewhere else
The symptom is somebody double booked while both calendars looked clear. The cause is half the meetings in one system and half in another, which is the ordinary condition of most small organisations and the reason clash reporting exists.
Connect the calendar you already use so the availability is real. Until that is done, treat the clash report as advice rather than as truth, because it can only see what it has been shown.
The recurring work is on a wall planner
The symptom is an annual service or a quarterly review that gets missed in a predictable proportion of cases, every year, and is discovered when a customer mentions it.
The fix is the habit above: the next one goes in when the last one is done. The wall planner is not the problem, the problem is that it is only read by whoever put it up, and it stops existing when they are away.
The daily view
What to look at, in what order
What slipped, before what is due
Overdue first, always. Something that was due yesterday and did not happen has already cost somebody something, and it is the item most likely to be quietly abandoned if the day starts at the top instead.
The right response to most overdue items is a decision instead of an action. Do it, move it with a reason, or close it. What corrodes a list is the fourth option, which is to look at it and do nothing.
Then the appointments, and what they need
Not to check where you are meant to be, which you know, but to check whether anything needs preparing. An appointment against a relationship carries the whole record with it, so the two minutes before a meeting are worth more here than anywhere else in the product.
Then today, in the order the day actually runs
Anything that depends on somebody else answering should be started early, because the clock on their reply begins when you send rather than when you finish. This is obvious and it is the single most common reason a task that could have been closed today closes on Thursday instead.
Then, once a week, what is coming
Look a fortnight ahead once a week. In any business with recurring commitments this is the review that prevents the annual pattern of missed work, and it takes about four minutes because most of what is there needs nothing except to be seen.
Not a planner
Six absences, each one deliberate
No project management. No dependencies between tasks, no critical path, no Gantt chart, no resource levelling. Tasks are commitments against records rather than a plan with a structure.
No time against a task. Time is recorded against a project on the delivery module, not against a task here. No job costing. If billing by recorded time is the core of your business, an agency or practice management product will serve you better.
No scheduling or dispatch. No route optimisation, no engineer allocation board, no live tracking. A maintenance business with six vans should read the honest paragraph on its own sector page before assuming otherwise.
No offline mode. It works on a phone as a web application. There is no native application and nothing works without a connection, which is a genuine limitation for anyone working in basements and plant rooms.
No workload balancing. You can see who has what. Nothing redistributes it, suggests a rebalance, or warns that someone is carrying three times as much as anybody else. That judgement is a management conversation and we would rather it stayed one.
Appointments report clashes rather than preventing them. The person booking usually knows something the calendar does not, so a clash is shown and allowed. If you want a system that refuses, this is not it, and that is a deliberate choice instead of an omission.
Six awkward moments
The clash it cannot see, the date with no time, and the task with no date
Every one of these is a case where the obvious behaviour is the wrong one, and the product had to choose.
The clash it can see, and the one it cannot
When an appointment is booked, the overlap check looks at the confirmed appointments belonging to the same person the new one is owned by. Book against your own diary and it reports your own commitments. Book on behalf of a colleague and it reports theirs.
What it cannot tell you is that an attendee is busy elsewhere, because an attendee is usually a customer whose diary this product has never seen and never will. A cancelled appointment does not count as a clash either, which is what you want: a meeting called off on Tuesday should not go on blocking Wednesday morning for the rest of the year.
The meeting that was called off
Cancelling marks the appointment cancelled and keeps the reason. It does not delete the row. Someone was told that meeting was happening, so the fact of it having existed is part of the history, and the cancellation is written onto the timeline of the record it concerned. Deleting would leave a customer holding a memory the system denies.
The meeting that moves
Rescheduling records the time it moved from as well as the time it moved to. That is the entry that settles the argument three weeks later about whether anybody ever said Thursday.
The hour that does not exist
On the morning the clocks go forward there is an hour that never happens. Availability is worked out in the organisation's own time zone from the actual instant rather than by adding a fixed offset, and a slot whose local time is not the local time asked for is left out rather than quietly shifted. Without that, a page whose hours end at two offers half past two, once a year, to whoever happens to look.
The date typed with no time on it
A due date entered as a day means the end of that day, not midnight at the start of it. Otherwise everything anybody types today is already late by the time it is saved, which is the fastest known way to teach people that the overdue count means nothing.
The task with no date at all
It is not overdue and it is not due today. It sits under what is coming up, and it stays there until someone gives it a date. That is deliberate rather than tidy: a task with no date is an intention, and the daily view says so by declining to put it in front of you every morning as though it were a commitment.
Two tables
What a task and an appointment actually hold
Two tables, and the columns that decide what the planning view can honestly say.
A task
A title, notes, one owner, a due date, a priority, and the record it is against. The subject is held as a kind and an identifier rather than as a column per kind, which is why the same task works against a relationship, an opportunity, a matter or a project without there being four sorts of task to learn.
Completion is a time instead of a tick, so what is recorded is that this was finished at half past four on the Tuesday, by whom, and reopening clears it again. The moment of creation is kept as well, which is the only way to see how long a thing sat before anyone touched it.
The priority is there and the daily view does not sort by it. Sorting by date is what makes the list a plan for a day. Sorting by priority is what makes everything on it important within a fortnight, and a list on which everything is important is a list that has stopped saying anything.
An appointment
A title, notes, a start and an end, a flag for all day, a place, a meeting address for the ones that happen on a screen, an owner, the record it concerns, a status, and a reason if it was called off. Attendees are held beside it rather than inside it, and an attendee may be somebody you deal with or a colleague, because both of them attend the same meeting and holding them apart would mean keeping two lists of one room.
Start and end are instants rather than a local reading of a clock. A wall clock time is ambiguous the moment two people in different places look at the same meeting, and it becomes wrong twice a year even for one person sitting still.
What neither of them holds
An estimate. A task does not carry how long it will take and nothing here invents one. That single absence is why the planning view reports open work as a count of things rather than as a number of hours: an estimate nobody entered would make the screen look precise and be wrong, and a number somebody plans a week against has to be one they can check.
End to end
One booking, followed from the link to the timeline
A hypothetical practice, invented for this page. Seven structural engineers who currently arrange every site visit by telephone.
They publish one booking page for initial site visits, in the name of the engineer who does them. It carries a slot length, a gap either side for travel, a minimum notice so nothing can be booked for forty minutes from now, and a horizon past which nothing is offered at all. Availability comes from that engineer's own diary, so anything already in it simply does not appear.
A prospective client picks eleven o'clock a week on Tuesday. At the moment they confirm, the offered times are worked out again instead of the time being taken on trust from the browser, because a time somebody sent back is not the same as a time that was offered, and because two people can reach the same slot within the same second and only one of them can have it. The organisation's database handles one request at a time, which is what makes that check reliable rather than probable.
Their address is not one the practice holds, so a relationship is created for them. Had they booked before under the same address, the existing person would have been used instead of a second copy of them appearing. The appointment is written against that relationship, the client is recorded as an attendee who has accepted, and a line goes on their timeline saying they booked through that page.
An entry goes into the audit trail attributed to the visitor rather than to anyone in the practice, because no one in the practice did this. The booking also raises an event, which is the thing a workflow can act on for organisations whose plan carries automation.
On the Tuesday it appears on the engineer's daily view under the meetings for the day, with the time and the place, alongside the tasks. After the visit, the task to send the report is completed, which records who and when, and that appears on the client's timeline underneath the booking that started it.
What has not happened is worth naming. Nothing was said to the client that the practice did not choose to send. The appointment is in this diary, and it is in the engineer's own calendar only if a calendar connection has been set up, which is exactly the seam where a double booking gets in.
Permissions
Who can see whose work, stated precisely
Tasks and the calendar are part of the core of the product instead of a module somebody buys. They are present on every plan, including the free one, and there is no reading of this page where a task turns out to cost extra. Booking pages are the one exception on this page: publishing one is a paid feature, and a free organisation asking for it is told which plan carries it rather than shown a form that fails.
What each role reaches
A standard member sees every task in the organisation and may change their own. A manager sees every task and may change the ones belonging to people in their teams, where somebody in no team resolves to their own work rather than to everyone's, which is the safe direction for that ambiguity to fall. A restricted member sees only their own tasks and their own appointments, and may still create work against any record they can reach. A read only member sees the lot and changes none of it.
Beneath the roles, a single record can be shared with one named person without changing their role at all, which is how the awkward one off case gets handled without someone being promoted to solve it.
Sensitive records reach the calendar too
A record marked sensitive is invisible to a role without the additional grant, and that rule follows through to appointments, because an appointment title usually carries somebody's name in it. A booking made under an email address belonging to a sensitive relationship produces a sensitive meeting, or the name would be legible from the diary by exactly the people barred from the record. Decisions of that kind are a data protection matter as much as a product one, and the Information Commissioner's Office publishes what is expected of an organisation holding them.
The booking page permission, and why it is stricter
Publishing a page in your own name needs the ordinary booking permission. Publishing one in a colleague's name needs it at full reach across the organisation, and the reason is not administrative neatness. A page that publishes when somebody is free is the exact inverse of when they are busy. Anybody able to create one for a colleague could read that colleague's diary off the public internet without ever being allowed to open a single appointment.
Five decisions
Five decisions, and the alternative each one rejected
An agenda, not a month grid
The design called for day, week and month views. What exists is one agenda grouped by day, soonest first. It answers the question people actually ask, which is what is happening, it works on a telephone without a second layout being maintained, and a grid can be put beside it the day someone asks for one. If you plan visually across a month and always have, this will feel thin, and that is a fair complaint instead of a misunderstanding.
Instants, not local times
Every start and end is stored as a moment in universal time and rendered in a named zone from the IANA time zone database. Storing what the clock said is simpler and it is wrong twice a year, and wrong immediately for two colleagues in different countries looking at one meeting. The cost is that all the difficulty moves into the availability arithmetic, where it is at least in one place and can be tested to death.
A clash reported, not refused
Rejected: refusing the booking, which is what most systems do. It does not prevent the double booking, it prevents the booking being recorded, and an unrecorded booking is invisible to everyone covering for you.
A count of open work, not a guess at hours
The planning view reports diary time in real minutes, because appointments carry a real start and end. Open work is reported as a number of things. Rejected: multiplying open tasks by an average duration, which would have produced a screen that looked like capacity planning and was arithmetic on an invention.
The offered slot recomputed, not trusted
A booking page is open to anybody at all, so the time that comes back from a browser is treated as a request rather than as a fact and the availability is worked out again before anything is written. Rejected: trusting the slot, which is faster and lets a determined visitor book at three in the morning on a Sunday.
Asked in week one
Asked about work and the calendar
Why report a clash rather than prevent it?
Because the person booking usually knows something the calendar does not. The first appointment was provisional, the two are at the same address, one is a telephone call that can happen in a car. A system that refuses to make the booking does not stop the double booking, it stops the booking being recorded, and the diary on the wall comes back within a month.
What does counting in working hours actually mean?
That a duration or a target skips the time no one was going to be working. A four hour response target given at four on Friday is due at eleven on Monday rather than at eight on Saturday. Elapsed time targets punish an organisation for having a weekend, and then everybody quietly stops believing the targets.
Can I assign a task to a team instead of a person?
Deliberately not. A task assigned to a team is a task no one has, and it is the most reliable way to lose work in any organisation. Assign it to someone, even provisionally. Reassigning is easy and takes seconds. No one noticing for three weeks is not.
Does it do recurring tasks?
You can create a task with a due date for anything, including the annual service or the six month review, and completing one is the natural moment to create the next. What it does not do today is generate a series automatically from a rule, which is a real gap for businesses whose work is mostly recurring and is named on the roadmap rather than described as coming.
Can I see somebody else's work?
If your role permits it. A standard member sees every task in the organisation and may change their own; a manager may change the ones belonging to their teams. The daily view itself is deliberately your own work only, because it exists to answer what needs you today. Seeing what colleagues are carrying is a separate screen, and it reports diary time in real minutes and open work as a count.
Does it connect to my calendar?
On the plans that carry integrations, calendar connections exist so appointments made here appear in the calendar your colleagues already watch. Which systems are connected is a shorter list than it will be, and the roadmap says so by name instead of describing it as coming soon.
Is there a mobile application?
It is a web application that works on a phone rather than a native app, and there is no offline mode. If your people work in places without signal, that is a genuine limitation rather than a detail, and we would rather say so here.
What is the difference between a task and a matter?
A task is a single thing someone has to do by a date. A matter, on the plans that carry the service module, is a piece of work with a target, a history and often a customer waiting on it, which may contain many tasks. Using tasks for everything is fine for most organisations and the moment it stops being fine is usually when a customer starts asking for progress.
Whose week this is
Four trades where the recurring date is the business
Maintenance and facilities businesses run on visits that recur, and the wall planner is the thing this replaces. Local service businesses chase quotes and come back a year later for the same job. Private practices and clinics run on appointments and recalls, and advice firms and brokers run on review dates that arrive whether anyone remembered them or not.
The parts of the product this sits beside are relationships, because a task is against a record rather than in a list, service and the portal, where the same working hours count towards a target somebody is waiting on, and follow ups and booking, which writes into this calendar.
Put a fortnight of promises in it
Every commitment you make for two weeks, against the record it concerns. Then be away for a day and see whether anybody needs to ring you.
Three people, a thousand relationships, no card and no time limit.