That feeling has a name and a measurement, and the measurement is worse than the feeling suggests.

What Leroy found

In 2009 Sophie Leroy published a set of experiments in Organizational Behavior and Human Decision Processes on what she named attention residue. People moved from one task to another under controlled conditions, and their performance on the second task was measured.

It was worse. Less accurate, slower, shallower. That much you might have guessed. The part worth knowing is what did not happen: it did not recover. There was no brief settling in period after which people were back to normal. The degradation persisted through the second task.

You do not arrive at the next task. You arrive with the last one still running in the background, and you do the new work with what is left.

The condition that makes it worse

Residue is not uniform. It is strongest when the task you left was unfinished, under time pressure, or emotionally charged.

Sit with that list for a second, because it is a fairly precise description of an ordinary working day. Observed office workers spend about eleven minutes on a thread of work before switching or being interrupted, and more than half of those threads get cut off before they are done. Unfinished, under pressure, and often the thing you care about. That is not the exception. That is the material.

Which changes what a block is for

The obvious lesson is protect the hour, and that is true but incomplete. The less obvious one, and the useful one, is that how the hour ends matters as much as whether you got it.

A block that closes at a natural stopping point leaves very little behind. A block that gets cut off mid sentence by a timer or a calendar alert leaves the maximum amount behind, and you carry it into the next thing and pay for it there. Two blocks of the same length can cost completely different amounts depending on how they finished.

Three things that follow

• End on a landing, not a cliff. Give the last five minutes of any block to closing: finish the paragraph, commit the change, write the one line that tells tomorrow where you were. It costs five minutes and saves more than that from the next block. In practice this means setting a ninety minute block and treating the last five as the landing, rather than setting eighty five and pretending.
• When you truly cannot finish, write the residue down. The open question, the next step, the thing you were about to try. One sentence, on the task itself rather than in a separate note, so it is waiting where you will land next time. Externalising it does more than help you remember, for reasons that turn out to be well studied.
• Put the transition inside the block. Back to back blocks guarantee residue, because the switch happens with no room to close anything. Book blocks fifty or eighty minutes long on the hour, not sixty or ninety. The ten minute gap is not slack. It is the mechanism working.

None of this asks you to be interrupted less, which is mostly not in your gift. It asks you to change what an interruption costs, which is.

This is one chapter of Blocks No. 01, a 26 page guide to time blocking. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

Twenty four people, followed with stopwatches

In 2005, Gloria Mark, Victor González and Justin Harris published a study at CHI with an unglamorous method: they followed twenty four information workers around their offices and recorded every switch they made. Not what people said about their day. What their day actually was.

They grouped work into what they called working spheres: threads of activity that belong together, the way a proposal and the emails about the proposal belong together. Then they timed them.

The number they report is 11 minutes and 4 seconds: the average time spent in a working sphere before switching to another one or being interrupted. The standard deviation they report alongside it is larger than the average itself, 18 minutes 9 seconds, which is a statistician's way of saying those stretches were wildly uneven. Some were seconds. A handful were long. Most were nowhere near long enough.

Eleven minutes is how long a piece of work lasted before something else took it away. Not on a bad day. On an average one.

Three more numbers, and then the shape appears

• 11.7 different threads of work touched in a single day, on average.
• 57 percent of them were interrupted before they were finished.
• When interrupted work was picked back up on the same day, which happened for 77 percent of it, the worker had passed through an average of 2.3 other threads first.

Read those together and something clicks. It is not that people are scattered by temperament. It is that a working day, left to arrange itself, arrives pre chopped. Eleven minutes is not enough to get properly into anything that requires holding several things in your head at once. And more than half of those short stretches did not even get to end on their own terms.

The resumption figure is the quiet one, and the one people skip. You do not return to a task. You return to a task through two other tasks, each of which leaves a little of itself behind. Sophie Leroy named that residue in 2009 and showed it degrades your performance on whatever you turn to next, and that it does not fade after a moment of settling in. It persists.

A number you have seen everywhere, which we are leaving out

You have almost certainly read that it takes 23 minutes and 15 seconds to recover from an interruption. It is on every productivity blog, in slide decks, in books.

There is no study. The figure traces back to a 2006 magazine interview with one of the authors above, with no method attached to it, and it has been repeated ever since without anybody going back to check. The underlying research on fragmented work is solid and worth citing, which is why the real numbers are in this piece. That one is not, so we left it out, and we would rather say so than quietly borrow the credibility.

What this changes about a block

If eleven minutes is the ambient rhythm of an unmanaged day, then blocking time is not a productivity flourish or a personality type. It is a deliberate act of aggregation: taking twelve scattered fragments that would have gone to six different things and forcing them to land on one.

It also sets a floor, and this is the practical part. A block shorter than the ambient fragmentation is not a block. It is a fragment with a name on it. Thirty minutes feels responsible and buys you nothing structural, because your day was already handing you stretches that long for free. If a block is going to do work that the day would not have done anyway, it has to be meaningfully longer than eleven minutes, which in practice means fifty at the low end and ninety when the work is hard.

One more finding, offered carefully because it is one study of twenty four people in specific offices. Working stretches in the morning were measurably shorter than in the afternoon. That is the opposite of the folk wisdom that mornings are the protected hours. Do not build doctrine on it. Do check your own pattern for a week before you hand your best work to a slot you chose by reputation.

This is one chapter of Blocks No. 01, a 26 page guide to time blocking. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

1. Task batching, for the fragments

Collect the small similar things and run them in one pass. Invoices, expenses, code review, the eleven replies that each take four minutes. Individually none of them justifies a block. Together they justify one, and running them in sequence means you pay the setup cost once instead of eleven times.

The trap: batching demanding work. Two hard things are not a batch, they are two blocks. Batch by how little thought a thing needs, not by which folder it lives in.

Use it when your day dies by a thousand small cuts and nothing big is actually late.

2. Day theming, for the many hats

Give each day a centre of gravity. Monday is planning and people, Tuesday and Wednesday are build, Thursday is clients, Friday is close and cleanup. You are not forbidding other work. You are declaring a default, so that the question "what should today be about" has already been answered by someone with more perspective than tired you at 9am.

The trap: it needs a week that is roughly repeatable. If your Tuesday is unrecognisable from one week to the next, theming will only give you a new way to feel behind.

Use it when you wear several hats and it is the switching between them, rather than the work itself, that leaves you flat by four in the afternoon.

3. Timeboxing, for the things that swell

Fix the duration in advance and treat it as the constraint: ninety minutes on the deck, then it ships as it is. The point is not speed. The point is that a fixed box forces you to decide what the work is actually for, usually within the first twenty minutes, which is a decision you would otherwise have postponed by polishing.

The trap: this is where somebody quotes the line about work expanding to fill the time available. That comes from a 1955 satirical essay by Parkinson about the British civil service, not from an experiment, and it gets cited as though it were a measured law. Timeboxing does work. Treat it as a decision forcing device rather than a law of nature, and you will use it in the right places.

Use it when the work has no natural end: research, tidying, polishing, anything that could always be slightly better.

4. Deep work blocks, for the one thing that matters

A long, defended, single subject stretch on the piece of work that actually moves something. No batching inside it, no second task held in reserve. This is the one that pays for the whole practice, and the one that gets sacrificed first, because it is the only one with nobody waiting on it.

The trap: treating it as the default shape. Most people cannot sustain more than one or two of these a day. Building a schedule that assumes four is the most reliable way to end the week believing the method failed.

Use it when the important work has been sliding for a week while the urgent work got done, which is most weeks.

Choosing, from the symptom

You do not pick one and marry it. In a normal week you will use three of the four. The skill is diagnosing which problem you actually have on Monday morning, and the fastest way in is the symptom rather than the technique.

• Busy all day, nothing to show. Fragmentation: the small work is eating the hours the big work needed. Batch the small into one pass, then one deep block for the big.
• Exhausted by mid afternoon, and not by the work. Role switching. Day theming, even loosely applied.
• Everything takes twice as long as it should. No natural stopping point. Timeboxing, with a stated output at the end of the box.
• The important thing has not moved in two weeks. Urgency is winning, and it always will unless the calendar intervenes. One protected deep block a day, first thing.
• Other people's meetings own your day. This one is not a personal method problem at all. It is a permissions problem, and no amount of technique fixes it alone.

Every one of the four fails the same way: the schedule was built for the day you wished you had.

If you are starting this week, do not adopt four techniques. Put a single deep block on tomorrow morning and batch the small work into one afternoon slot. Theming and timeboxing are refinements and they will still be there in a fortnight, by which time the first two will have either taken hold or told you something useful about your week.

This is one chapter of Blocks No. 01, a 26 page guide to time blocking. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

The four lengths, honestly

• 25 to 30 minutes. One small defined thing, or a batch of near identical fragments. Not a block for thinking work. Observed office workers already get stretches around eleven minutes for free, so half an hour sits barely above the ambient fragmentation of a normal day and buys you almost nothing structural.
• 50 minutes. The workhorse. Long enough to get in, short enough to fit between commitments, and it leaves ten minutes on the hour for closing properly.
• 80 to 90 minutes. Real depth. This is where work that has to be held in your head all at once actually happens. One or two of these in a day is a strong day, not a modest one.
• Half a day. Only for work with a genuine warm up cost: a hard debugging session, a first draft, a design pass. Rare, and worth defending out loud when you schedule one.

The 60 percent rule

Do not block more than about 60 percent of your working hours. On a seven hour day that is a little over four hours of blocked work, and when you first write it down it will feel like giving up before you have started.

It is not. The remaining 40 percent is where the day's actual events live: the thing that broke, the question that could not wait, the meeting that ran over, and the twenty minutes you spent recovering from all three. A day blocked at 100 percent is not an ambitious plan. It is a plan that is guaranteed to be wrong by eleven in the morning, and a plan that is always wrong stops being consulted.

Blocking less is not lowering the bar. It is the difference between a plan you keep using and one you stop opening.

The failure this prevents, specifically

Nearly everyone who abandons time blocking abandons it in week two, and almost always for the same reason. They blocked every hour. Reality took four of them. By Thursday the calendar had become a daily record of falling short, and nobody keeps opening a document that exists to tell them they failed.

The unblocked 40 percent is also where your estimation error gets absorbed instead of cascading. Every block that runs over pushes the one after it, so a thirty percent underestimate on the first task of the day becomes an entirely fictional afternoon. Gaps are not politeness. They are the shock absorber.

What a realistic day looks like

A deep block of ninety minutes in the morning on the one thing that matters. A quarter hour after it to land, before anything else starts. The meetings you did not choose. A second pass of eighty minutes on the same piece of work in the afternoon, because a second pass on the same thing starts warm while a different thing starts cold. One fifty minute batch for everything small, at the hour when careful thinking is expensive and sorting is cheap. Then an hour and a bit left deliberately unclaimed, and ten minutes at the end to plan tomorrow.

Count it and that is three hours and fifty minutes of work you chose, in a working day of seven and a half hours. Fifty two percent. It looks thin on paper and it is more than most weeks deliver.

The guide has the whole day drawn out, plus a printable weekly template. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

Three things that sit around it

• The meeting itself. Thirty minutes each, three hours across six people.
• The approach. The stretch before it, too short to start anything real, spent half waiting. Call it ten minutes each, another hour.
• The residue. Degraded attention on whatever comes next, because part of you is still in the room. Another ten minutes each, another hour.

That already doubles the nominal cost, from three hours to five. Those minute figures are reasoned estimates rather than measurements, and it is worth saying so plainly: the direction is well supported by the research on task switching, the exact size for your team is not. Use it to make an invisible cost arguable, not as a number to quote at somebody.

The fourth thing, which is the real one

A morning that could have held one ninety minute block now holds two short ones. This is the cost that matters, and it does not add up neatly, because it is not additive. It is a change of shape.

A meeting in the middle of a morning does not take thirty minutes out of it. It takes the morning out of it, and hands back two fragments.

Two forty minute gaps are not equivalent to one eighty minute stretch. For anything demanding they are worth considerably less: the fixed cost of getting into the work is paid twice, and forty minutes does not reach half the depth that eighty does. You cannot recover the difference by being more focused in the fragments.

Three rules that follow directly

• Push meetings to the edges. The same meeting at 09:00 or 16:00 costs a fraction of what it costs at 11:00, because it removes time from the day instead of cutting the day in half. Applied to a team's recurring meetings, this single change is usually the largest gain available, and it costs nobody anything.
• Cluster rather than spread. Three meetings in a row cost one interruption. The same three spread across a day cost three, and destroy every block between them. A stacked afternoon looks worse on a calendar and is cheaper in practice.
• Count the room, not the meeting. Before adding the sixth person, ask what the invitation costs them given everything above. Optional attendance is a real answer, but only if declining is genuinely normal on your team rather than technically permitted.

Why this is a team problem and not a personal one

Almost everything written about time blocking quietly assumes you control your own calendar. Most people do not, and telling them to try harder is not advice, it is an accusation.

If any colleague can drop a meeting into any open slot, your blocks are decoration. You can defend them by declining, which spends a little social capital every single time, or you can change the structure once so the calendar declines on your behalf. Only the second one still works in a fortnight.

The cheapest version: blocks that are visible and marked busy, with a title specific enough for a colleague to judge urgency. "Deep: Q3 pricing model", not "Busy". The specificity is what makes it socially survivable, because "Busy" invites the question and a named piece of work usually answers it.

The version that works better than any individual habit: one recurring window where the team does not schedule internal meetings. Not tries not to. Does not. When it is your personal rule, protecting it makes you the difficult one. When it is the team's rule, protecting it makes you compliant. Same behaviour, opposite social cost.

The last part of the guide is entirely about blocking time with colleagues who can book you. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

Start with the thing worth internalising before any technique: this is the normal case, not the exception. In the most cited observational study of office work, 57 percent of all threads of work were interrupted before they finished. A method that only functions on undisturbed days is not a method.

The expensive instinct

The instinct is to abandon the plan and go reactive for the rest of the day. It feels like realism. It is the single most expensive move available, because you do not only lose today. You lose the evidence that planning was worth doing, and next Tuesday you do not bother.

A broken plan is not a failed plan. It is a plan that told you the truth early enough to do something about it.

The four minute triage

• Declare the day broken, explicitly. Out loud, or in a line of text. The ambiguity is what does the damage: half pretending the plan still holds while quietly doing something else gets you neither the plan nor a clean improvisation.
• Rescue one block, not four. Look at what is left and save the single most important one. Move it, shrink it if you must, but keep one. Ninety minutes becoming fifty is a win. Ninety becoming nothing is how the habit dies, because your sense of whether this works is built almost entirely out of these moments.
• Move the rest with a date, not into the void. Everything you drop goes somewhere specific: a slot later in the week, or back on the list, unscheduled and honestly so. What it must not do is silently evaporate, because that is what teaches you the calendar lies. Rescheduled work stops occupying you. Vanished work does not.
• Write one line about what broke it. Not for self improvement. For pattern detection. Four weeks of these lines show you what a single Tuesday cannot, and what they usually show is structural rather than personal.

The five ways it usually breaks

After a month, most breakage sorts into five buckets. Each has a different fix, and applying the wrong fix is the main reason people conclude the method does not suit them.

• A genuine emergency. Rare, real, and nothing is wrong with your system. Triage, rescue one block, move on without building a story about it.
• Someone booked over your block. Not a personal failure. A permissions problem, and it needs a shared rule rather than more willpower.
• The work was much bigger than the block. Estimation, every time. Correct the estimate, and split the task until a piece of it actually fits.
• You did not want to start. Usually the task is vague, not that you are undisciplined. Rename it to the first concrete action. "Open the file and write the header" is a block you can start.
• It happens every week at the same time. This is not breakage. This is your real schedule disagreeing with the one you wrote. Stop blocking that slot and give it to whatever always takes it.

The one about guilt

There is a specific feeling that comes with opening a calendar full of blocks you did not honour, and it deserves addressing directly, because it is the actual reason people delete the whole thing rather than adjust it.

A block is a decision made yesterday with yesterday's information. When today turns out different, that decision is not a debt you defaulted on. It is an estimate that got updated, which is what estimates are for.

If it helps, change what you count. At the end of a week, do not count how many blocks survived. Count whether the one thing that mattered each day moved. Most people find that number is a great deal better than their sense of the week, and the gap between the two is precisely the guilt talking.

For what it is worth, somewhere between half and two thirds of blocks honoured is a genuinely good week for anyone who has colleagues. If you are hitting ninety percent you either have unusual control over your time, or you are not blocking the work that actually matters.

The guide has the triage on a printable one page sheet, along with three other tools. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

There is decent evidence that it stops much earlier than that, and much more cheaply.

The experiment

In 2011 Masicampo and Baumeister ran a series of studies on unfulfilled goals, published in the Journal of Personality and Social Psychology. First they reproduced the familiar effect: an unfinished goal intrudes. It produced intrusive thoughts during an unrelated reading task, made goal related words more mentally accessible, and degraded performance on an unrelated anagram task. The unfinished thing was, measurably, taking up room.

Then they added one step. Some participants were asked to make a specific plan for the unfulfilled goal. Not to do it. Not to make progress on it. Just to plan it, concretely.

The interference went away. Making the plan eliminated the activation and the interference effects. And the effect was mediated by how earnest the plan was: the people who showed no interference were the ones who genuinely intended to carry it out. You cannot fool yourself with a plan you do not mean.

Nothing got done. Something got decided, and the decision was enough to stop the noise.

What that reframes

If this holds, then blocking out your Thursday is not administration you do before the work. It is a large part of the benefit, collected in advance.

It also explains something people report after their first honest planning session and then feel slightly silly about: not a sense of accomplishment, which would be unearned, but quiet. Nothing had moved. Something had been decided, and that turned out to be the part that was making the noise.

The word doing the work is specific

The neighbouring literature points the same way. Implementation intentions are plans shaped "when situation X arises, I will do Y". A 2006 meta analysis by Gollwitzer and Sheeran, across 94 independent tests and more than 8,000 participants, found a medium to large effect on goal attainment, d = 0.65. A 2024 update across 642 tests found the picture more conditional, depending on plan format and motivation, which is what usually happens to a finding after twenty years of scrutiny. The direction has held up.

Two notes on citing this honestly, since both mistakes are everywhere. The number belongs to the 2006 meta analysis, not the much quoted 1999 paper, which introduced the idea rather than measuring it at that scale. And the Masicampo and Baumeister work sits in a corner of social psychology now under real scrutiny for replication, so treat it as strongly suggestive rather than settled. We lean on it because it points the same way as a far larger body of work, not instead of it.

What has not held up at all is the vague version. "Work on the report" is not a plan and does not buy you the quiet. "Tuesday 9 to 11, first draft of the report, at my desk" is. A calendar happens to be the most natural place to store a plan in that shape, because it forces the when and refuses the vague.

The practical version

Ten minutes before you close the laptop, not ten minutes after you open it. Four questions: what is already true about tomorrow, what is the one thing that must move, where does it go and how long does it get, and what is not happening.

The reason it goes at the end of the day is exactly the finding above. An unplanned tomorrow keeps its loops open all evening. Planning in the morning means you carried the noise home for nothing. And at half past five you still know what today actually cost you, which at nine the next morning you will have conveniently forgotten.

This is one chapter of Blocks No. 01, a 26 page guide to time blocking. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

It was not unusual, and there is a clean demonstration of why, from 1994.

Thirty seven students and their own thesis

Buehler, Griffin and Ross surveyed thirty seven psychology students about their honours thesis. Final semester, on a project they knew intimately and cared about a great deal. If anyone was going to estimate well, it was these people on this task.

They predicted an average of 33.9 days. The actual average was 55.5 days, about 64 percent longer.

The detail that makes it useful is what happened when the researchers pushed. Students were also asked for a best case, if everything went as well as it possibly could: 27.4 days. And a worst case, if everything went as poorly as it possibly could: 48.6 days. Reality came in at 55.5.

The average outcome was worse than their own worst case. Not the average case. The worst one they could imagine.

And when asked for a date they were 99 percent confident of hitting, only about 30 percent of them made it.

Three corrections that actually work

The reason this needs mechanical correction rather than effort is that the bias survives knowing about it. You have just read the study. You will still argue the next estimate down, because this particular task is different, and it always is.

• Use the outside view, not a better inside one. Do not re examine the task and think harder about it. That is the inside view, and it is what produced the bad number. Ask instead: how long did the last three things like this actually take? The question is boring and far more accurate. It does require you to record actuals, which takes ten seconds at the end of a block.
• Apply a fixed multiplier, and do not negotiate it. Start at 1.5 on your first instinct and adjust after a month of real data. Your gut says an hour, you block ninety minutes. Every time, with no case by case debate, because the debate is where the bias lives.
• Split until a piece genuinely fits. If a task will not fit in a block, the problem is usually the task. "Write the report" is a project wearing a task's clothes. Cut it until you can picture the first sentence you would type. That is how you know it is small enough to start, which is a different and more useful test than whether it sounds small.

The part that compounds

Underestimation does not break one block. It pushes every block after it. A thirty percent error at nine in the morning becomes an entirely fictional afternoon, and by three you are not running a plan, you are running an apology.

That is the real argument for keeping your day only about sixty percent blocked. The unblocked forty is not spare capacity you failed to use. It is where the error gets absorbed instead of cascading through everything you scheduled after it.

This is one chapter of Blocks No. 01, a 26 page guide to time blocking. Free PDF, no email, and every number in it traced to the paper it came from. Get the full guide

Sit with that for a second, because it is not the damning statistic it first looks like. Two out of three is a very good hit rate for something that costs a fraction of a cent and takes forty seconds. It is a terrible hit rate for something you are told to trust and forget.

Almost every AI teammate on the market is sold on the second story. Delegate it, walk away, it is handled. Then the third task comes back wrong, quietly, in a place nobody was looking, and the thing that was supposed to save an afternoon costs a week. The failure is not the model being bad. The failure is a product that promised you would not have to look.

Design for the one in three, not the two in three

So we started from the opposite assumption. Assume it will sometimes be wrong, and make being wrong cheap. That single decision shaped everything about how an AI teammate works in UnaTask.

• The work comes back as a comment on the task, written by the teammate, with any files attached. It does not overwrite anything you wrote.
• The task then moves to Review. Not Done. Somebody looks before anything counts as finished.
• Under the work there are three buttons: Good as is, I fixed it, Not usable. Ten seconds, and the record of what happened stays on the task.
• Nothing starts on its own unless you switch it on. Every project has its own toggle, and a paused teammate stays on the team without picking anything up.
• There is a ceiling on how many runs a workspace can do in a day, so a loop or a bad template cannot quietly spend your afternoon.

None of that is dramatic. That is the point. When the wrong answer lands in a comment on a task that is sitting in Review, the cost of the one in three is thirty seconds of reading and a click. When the wrong answer lands in a document that says Done, the cost is whatever happens next.

Reviewable beats autonomous

There is a version of this product we could have built where the AI moves your calendar, closes your tasks and files things without asking. It demos beautifully. We have watched people use tools like that, and what actually happens is a slow loss of trust: you start checking everything it did, which is strictly more work than doing it yourself, and then you stop using it.

The teams getting real value out of AI right now are not the ones who handed over the most. They are the ones who put it where a human was already going to look. A draft on the task it belongs to, in front of the person who asked for it, is that place. It is also, not by accident, the only shape where the failure rate stops mattering very much.

And the one in three gets better with use, because a correction is not thrown away. Paste back the version you actually used and that becomes a rule the same teammate carries into its next job. The number is not a fixed property of the model. It is a property of how much your teammate has been told, and by whom.

We do not sell autonomy. We sell work you can look at in thirty seconds and either take or send back.

This is the quiet tax on almost all AI at work. The thinking is done and the artefact is not, so a person spends twenty minutes converting prose into the thing the prose was always meant to be.

The work arrives as a file, on the task

An AI teammate in UnaTask can attach real files to the task it was working on. Ask for the supplier comparison as a spreadsheet and a spreadsheet is what lands, in the attachments of that task, uploaded under the teammate’s own name, next to whatever your colleagues have put there.

• The prose stays in the comment, where prose belongs, so the task stays readable.
• The deliverable becomes an attachment on the task, which is where your team already looks for files.
• It is a normal attachment, so downloading, sharing and keeping it work exactly as they always have.
• The teammate’s name is on the upload, so months later it is obvious where the file came from.

A useful side effect: nothing new had to be invented for this. Files on a task were already a thing, an AI teammate is already a member of the team, so the work lands in the place your team already trusts rather than in some special AI area with its own rules.

What this is really competing with

Not Asana, not the other planners. The honest competitor here is the second browser tab where you already paste things into a general assistant. That tab is good at thinking and bad at finishing, because it cannot put anything anywhere. It hands the result back to you and you become the courier.

The whole difference is what happens in the last ten seconds of the job. The comparison lands as a file, on the task, in the project, in front of the person who asked, with a Review step so somebody checks it. Nobody had to carry anything from one window to another.

The thinking was never the bottleneck. Getting the result into the place it belongs was.

The copying is not the annoying part. The annoying part is that none of it is anywhere. The request is in a chat log, the result is in a document, and the task it belongs to has no idea any of this happened. A week later nobody can find which version was the real one.

The teammate goes on the task, not in a tab

An AI teammate in UnaTask is a member of your team. It has a name, a face, a job description, and it appears in the assignee picker next to everybody else. So you give it work the way you give anyone work: you put it on the task.

• Add the teammate to the assignees of a task. That is the whole action. There is no separate button and no prompt to write.
• The task itself is the brief: the title, the description, the checklist, the project it sits in.
• It starts within about a minute. While it works, the task shows how long it has been going and how long that teammate usually takes.
• The work comes back as a comment on the same task, with any files attached, and the task moves to Review.

If something goes wrong it says so on the task, in a comment, and tells the person who asked. No silent failures, no empty result you notice three days later.

Why the task is the right place

Because everything the work needs is already there, and everything the work produces belongs there. The brief does not have to be re explained, because the task is the brief. The output does not have to be filed, because it lands on the thing it was for. And the history stays in one readable line: this was asked, this came back, this is what we thought of it, this is the version we used.

It also means the rest of your team can see it. An AI teammate’s work is not hidden in somebody’s private chat history. It is a comment on a shared task, with a name on it, in the project where the work lives. Your colleague can read it, disagree with it, or pick it up on Monday.

The small shape of this matters more than it sounds. There is nothing new to learn, because you already know how to assign a task. The AI is not a mode you enter. It is a name in a list you were going to open anyway.

If you have to explain the project before the work starts, the AI is in the wrong place.

See how AI teammates work

Marc fixes the same two things every time: it writes too long, and it keeps using the old product name. He has typed both corrections perhaps thirty times. A human colleague would have needed telling twice, and would have been quietly annoyed by the third.

That gap is the whole difference between a tool and a teammate, and it has almost nothing to do with how clever the model is.

A correction is worth more than an opinion

When work comes back from an AI teammate, there are three buttons under it: Good as is, I fixed it, Not usable. The middle one is the valuable one, because it asks for the version you actually used. That paste is the richest thing you can give it. It is not a complaint about what was wrong, it is a demonstration of what right looks like, with both drafts sitting side by side to compare.

• Corrections and notes are distilled into short rules, held against that specific teammate.
• A strong signal, a pasted correction or two people saying the same thing, becomes an active rule straight away.
• A weaker signal waits as a proposal until somebody agrees with a click.
• You can also just write a rule by hand, if you already know what you want and would rather not wait for it to be learned.
• Every rule is listed on the teammate, so you can read what it thinks it knows, and switch one off when it stops being true.

That last point is the one we would defend hardest. A system that learns quietly, where you cannot see what it learned, is a system that will surprise you badly one day. Every rule is visible, attributable and one click from being turned off.

What it feels like after a month

Marc pasted his shorter rewrite twice and typed one rule by hand about the product name. He has not corrected either thing since. The drafts arrive short, with the right name in them, and his editing is now about the argument rather than the housekeeping.

It is not magic and it is not a smarter model. It is the ordinary thing that happens with a new colleague, which is that after a few weeks of being told, they stop needing to be told. The only unusual part is that software normally refuses to participate.

Showing it the version you actually used is worth more than any number of stars out of five.

This is the normal experience, and the normal conclusion drawn from it is the wrong one. The lesson is not that AI teammates are unreliable. It is that nobody tells you the shape of the work that suits them, so everyone finds out by donating a task and seeing what happens.

So here is the shape, written down plainly, from watching what comes back well and what does not.

The test: does it end in words or a file?

An AI teammate in UnaTask produces two things: a comment on the task, and files attached to it. That is the whole output surface. So the question to ask before you delegate is simply whether the finished job could be handed to you as writing or as a document. If yes, it is a candidate. If the job ends in a decision only you can make, or a conversation with a person, or a change inside a tool you have not connected, it is not.

• A first draft of something you will rewrite anyway. The blank page is the expensive part, not the editing.
• A summary of something long, with the bits that matter pulled out.
• Research pulled together into one place, so you start from a page instead of a search box.
• A checklist or a plan broken into steps, which you then argue with.
• Three options to choose between, when your real problem is that you cannot get started.
• A file: a spreadsheet of the numbers, a document in the format you asked for.

And the other side of the line, just as usefully:

• Anything where being 90% right is worse than not doing it. A legal clause, a price, a number that goes to a client.
• Work that needs a fact only a person in your company holds and nobody has written down.
• Anything that has to go out under your name without you reading it. That is not delegation, that is a hope.

The instructions matter more than the task

The other half of Nadia’s problem is not what she asked for, it is what her teammate knew. An AI teammate has a job description and a set of instructions you write once when you add it to the team, and it inherits the context of the workspace it lives in. A teammate told it writes support replies in your tone, with your product names, will do that job forever. A teammate told nothing will produce something generic and you will blame the model.

Then it gets better on its own terms. Every piece of work comes back with three buttons under it, and if you paste in the version you actually used, that correction becomes a rule the same teammate carries into the next job. The second draft of anything is noticeably better than the first, because by then somebody has told it something true.

Same month, different Nadia. She has stopped thinking of it as a clever thing that might do her work and started thinking of it as the colleague who does the first version. She hands it the draft, the summary, the sweep of research. She keeps the judgement, the pricing and the conversation with the client. Nothing about that division has changed in twenty years of working with junior colleagues, which is probably the point.

Give it the blank page, keep the decision. That line has not moved just because the colleague is software.

See how AI teammates work

So the list quietly lies. It says seven things are open when three of them shipped last week. You start a branch and forget which task it was for. And the plan for today is really just the top of the list plus a hope that you get to it.

You do not need a heavier process. You need the three things that actually matter, the task, the code that closes it, and the time to do it, in one place. That is the whole idea here.

The task and its pull request, together

Open a task in UnaTask and link the pull request that closes it, either by searching your open pull requests or by pasting a link. From then on the task shows its live state, open, draft, merged, or closed, and whether the checks pass. No more wondering which branch went with which task, or opening GitHub just to remember where something stands.

You can even skip UnaTask entirely: drop the task reference into the pull request description or the branch name, and it links itself the moment the pull request opens.

Give the work a real slot on your week

This is the part a code-only tool cannot do. Drag the task onto your week and it claims a real block, sized to how long the work takes, next to your actual calendar. Plan the coding, and plan the review separately, because reading a diff carefully is its own kind of focus. Your day stops being a list and becomes a plan you can finish.

One place for the task, the pull request, and the hour you will actually spend on it.

Let a merge close the loop

When the pull request merges, the task can move to Done on its own. The list finally tells the truth without you tending it, which is exactly what you want when you are the only one tending it.

Your Issues, planned like everything else

The same GitHub connection pulls your Issues in as tasks, with priority from the labels and a due date from the milestone. So the bug you filed at midnight lands on your board and, tomorrow, onto a slot on your week, instead of living in a list you never open.

That is the shape of it. Fewer tabs, a plan that matches the repo, and a day you can actually finish. Being a team of one is enough work already.

See the full GitHub integration

Start for free

It is a small gap, but it adds up. Someone asks whether the login work shipped, and the honest answer is a shrug and a trip through GitHub. The plan and the repo drift, and standup turns into a status meeting.

A pull request is the work on a task that already exists, not a new task of its own. So in UnaTask it links to that task, carries its status onto it, and can close it when it merges. Here is how to set that up, start to finish.

First, connect GitHub once

Open Settings, then Integrations, then GitHub, and hit Connect. You sign in on GitHub and grant access once. The connection covers both linking pull requests and importing Issues, and it reads private repositories too, so nothing about your setup has to be public.

The token stays on our server and never touches the page. You only do this step one time.

Link a pull request to a task

Open the task and find the GitHub pull requests section. There are two ways to attach one:

• Search your open PRs. Start typing and your own open pull requests show up to choose from, across every repository you can see. Pick one and it links.
• Paste a link. Have a specific pull request in mind, or a teammate’s? Paste the link and it attaches.

A task can hold as many pull requests as the work needs, so a change that spans the API and the web app can carry both, each with its own status.

Or let the pull request link itself

If you would rather not open UnaTask at all, use the Copy reference button on the task. It puts a short marker on your clipboard. Drop that marker into the pull request description or the branch name, and the pull request attaches to that task on its own the moment it opens. Your normal GitHub flow does the linking for you.

Follow the status without leaving the task

Once a pull request is linked, its live state sits right on the task: open, draft, merged, or closed. A green tick tells you the checks pass, a clear mark tells you they do not, so you can see whether the code is ready without opening GitHub. You can refresh a link any time, or jump straight to it on GitHub in one click.

Across a whole project, those badges become a quiet map of what is coding, what is in review, and what already merged.

Decide what a merge should do

In the GitHub settings you pick what happens to a task when its pull request merges, for your whole workspace:

• Just update the badge. The task shows the pull request as merged and you decide what comes next.
• Notify the assignees. The people on the task hear that their code landed, with no one posting an update by hand.
• Move the task to Done. The task closes itself when the code ships.

The task and the code finally tell the same story, without anyone keeping them in sync by hand.

While you are there, pull your Issues in too

The same connection imports your GitHub Issues as tasks. Pick the repositories you care about and bring their open Issues in, on demand or automatically. Priority comes from the labels, the due date from the milestone, and a link back to the Issue rides along. Then you can time block them like anything else on your week.

Run that same moment again. You open the pull request, the task already knows, and when the checks go green and it merges, the task moves to Done on its own. Nobody asks whether it shipped, because the board already said so.

See the full GitHub integration

Start for free

So the board fills with cards that are already finished. The lie is minor on any one task and expensive across a whole project, because now nobody trusts the columns and you are back to asking people what really shipped.

When a task in UnaTask is linked to the pull request that closes it, the merge itself can move the task. You choose what that means for your workspace, and then the last mile takes care of itself.

Pick what a merge should do

In Settings, under GitHub, there is one choice for the whole workspace:

• Just update the badge. The task shows the pull request as merged and nothing else moves. You keep the last word.
• Notify the assignees. The people on the task hear that their code landed, so the update happens without anyone posting it by hand.
• Move the task to Done. The task closes itself the moment the pull request merges.

It is one setting, and admins own it, so the behaviour is consistent for everyone in the workspace.

What it needs to work

The task and the pull request have to be linked. You can link one by hand from the task, by searching your open pull requests or pasting a link, or you can let it link itself: drop the task reference into the pull request description or the branch name and it attaches when the pull request opens. After that, the merge does the rest.

The work reports itself finished, instead of waiting for someone to remember.

When to choose Done, and when to choose Notify

If a task usually maps to a single pull request, Move the task to Done is the clean choice: one merge, one finished task. If your tasks tend to carry several pull requests, a merge closing the task on the first one may be too eager, so Notify the assignees keeps you informed while you decide when it is truly done. You can change the setting any time as your workflow settles.

Either way, the badge on the task always shows the real state, merged and all, so you are never guessing. The only question is how much you want the merge to do on your behalf.

Merge the pull request and watch the task move, or watch the assignees get the news, without opening the board to do it yourself. The finish line takes care of itself.

See the full GitHub integration

Start for free

The board says In progress. The pull request merged two days ago. Nobody moved the card, because moving the card is the kind of small chore that always loses to real work. So the plan drifts from the code, and the standup turns into a status meeting to close the gap by hand.

The fix is not more discipline. It is letting the work report itself. In UnaTask a pull request links to the task it closes, carries its status onto the board, and can finish the task when it merges. Here is what that changes for a team.

Every task shows the code that closes it

Open any task and its linked pull requests sit right there, with their live state: open, draft, merged, or closed, and whether the checks pass. A change that spans the API and the web app can carry both. Anyone looking at the task can see what is actually happening in the repo, without a single question in chat.

The board tells the truth on its own

When a pull request merges, the task can move to Done by itself, so the column you are looking at matches what really shipped. You set the behaviour once for the workspace:

• Just update the badge when you want to keep the last word.
• Notify the assignees so the people on the task hear their code landed.
• Move the task to Done so the board closes the loop for you.

Review load stops being invisible

Reviews are real work, but they rarely show up on anyone’s plan. With pull requests on the tasks, you can see how much is waiting on review across a project, and treat it like the work it is. Drag a review block onto your week next to the coding, so the time it takes is planned, not squeezed.

Standup gets shorter when the board already answers the question you were about to ask.

It links itself, so nobody has to remember

The habit that makes this work has to be effortless, so it is. Copy the task reference and drop it in the pull request description or the branch name, and the pull request attaches to the task on its own. The linking happens inside the flow the team already has, not as one more step to forget.

And the same GitHub connection brings your Issues in as tasks, priority from the labels and due date from the milestone, so the planning side and the code side share one source of truth.

Run that standup again. The board shows what merged overnight, what is still in review, and what has not started, because the pull requests put it there. The three questions answer themselves, and you get the ten minutes back.

See the full GitHub integration

Start for free

The strange part is that you already know the rules in your head. Do the urgent things first. Keep the afternoons for deep work. Do not put anything on Friday. You just have to translate all of that into a real calendar, by hand, every single week, and that translation is the boring part nobody has time for.

So we let you say the rules out loud instead. Open Smart Schedule, type a plain sentence, and your unscheduled tasks drop into your real free time on their own.

Say it how you would say it to a person

Free up my afternoons this week. Do not schedule on Fridays. Focus everything in the morning. You write the intent, and it reads it as a rule. Then it packs your tasks into the gaps around your meetings, your availability and your Google Calendar, over the next couple of weeks, soonest deadline and highest priority first.

When it is done, every task comes back with a one line reason it landed where it did. Fits before its deadline. Next open morning. Afternoons kept free, as you asked. No black box, just a plan you can read. And if the sentence feels like too much, skip it entirely and press the button, it still respects your deadlines, your priorities and your calendar.

The AI reads your intent. A plain engine owns the clock.

Here is the part that matters. The AI only turns your words into rules and writes the explanations. It never picks the actual times. A deterministic scheduler does that, stepping through your real free slots, so it can never invent an hour that does not exist or drop a meeting on top of another one. The creative bit is kept away from the clock on purpose.

You keep the judgement. It keeps the calendar.

The same Monday, without the Tetris

Run that Monday again. One sentence, and the week is planned, the mornings packed, the afternoons left open the way you asked. When a meeting moves on Wednesday, you do not rebuild anything. And when Friday turns out to be a write off, clear my Friday wipes the tasks it placed and leaves your real meetings untouched, so you can start the plan over in a breath. Open your calendar, hit Auto schedule, and get your week back.

The cost is not just the fourteen messages. It is that the meeting starts on the back foot, because the first thing it proves is that your team could not find an hour together. For a kickoff, that is a strange first impression to make.

A group link takes the whole search off the table. You add the co-hosts who must be there, and the link only ever offers times when every one of them is free.

One link that already did the math

Under the surface it is doing the thing the email thread was trying to do by hand. It takes each host’s hours and each host’s calendar, the real one, meetings and all, and shows only the overlap. If any one of you is busy, that time simply is not on the page. The client cannot pick a slot that half the room will miss, because those slots were never offered.

When they pick one, everyone who was required lands on the meeting. Each host gets the event on their calendar and the invite in their inbox, so nobody is added as an afterthought later. One click on their side, three calendars booked on yours.

Stop coordinating people. Let the link find the overlap.

Group or round robin

It helps to know which link you want. A group link is for everyone in the room at once, when the meeting needs all of them: the kickoff, the review, the panel. A round robin link is the opposite, one meeting for any one of several people, spread across the team. Same booking page for your guest, two very different jobs behind it.

So the next kickoff request does not open a thread. It gets one link, the client picks the single hour that works for all three of you, and the meeting starts on the front foot instead of apologising for being late to itself. Open a booking link, choose the group type, and add the people who need to be there.

So the fix becomes a chore. Someone glances at who is quiet this week, forwards the lead, waits for a reply, forwards it again. The link that was supposed to save time turned into a small dispatch desk run by a human, and the human is tired of it.

A round robin link is the version where the link does the dispatching. You share one address, and each booking is handed to a person in the group on its own.

How the hand off works

You pick who is in the pool, and you give each person a share, a simple percentage. When someone books, the link looks at who is actually free for that time and gives the meeting to whoever is furthest behind their share. Over a week the demos spread the way you asked: an even split if everyone is at the same number, a heavier load on the people you weighted up, a lighter one on the people you weighted down.

A time stays bookable as long as at least one person in the pool is free for it, so the link almost never looks empty. The soonest open slot is tomorrow morning with whoever happens to have the gap, not a fortnight out because one calendar was full.

• Set a share per person, and change it whenever the load shifts.
• Drop a share to zero to rest someone without taking them out of the group.
• A reschedule stays with the same host, so your guest keeps the person they were going to meet.
• You need at least two people for it to rotate.

The link is the router. Fairness is just a number you set.

When to reach for it

Round robin is for the meeting that any one of several people can run: the sales demo, the support call, the intro chat, the interview screen. Anywhere the job is get this in front of a human soon, and it matters less which human, this is the setting that keeps the wait short and the load even.

The same book a demo link goes in the same footer. Nothing changes for the person clicking it. Behind it, the meetings fan out across the team on their own, and the quiet dispatch desk that used to be a person is just the link doing its job. Open a booking link, set it to round robin, add your people, and give each a share.

This is the quiet tax of a busy inbox. It becomes a second to do list, one that never talks to your real one. Things fall into the gap between the two, and you end up scrolling your own mail like an archaeologist, hunting for the thing you know someone asked you to do.

So we put a small button where the email already is. Open Gmail with the UnaTask extension and every message grows a Create a task action.

One click, and the email is a task

Click it and the email becomes a real task. The subject is the title, the sender and the message come along in the description, and a link back to the original thread rides with it, so replying is always one click away. If the email names a time, by Thursday, end of the month, the task gets that deadline, picked straight out of the text. It lands in your Inbox by default, or in a project you choose right from the button.

Click the same email again tomorrow and it just opens the task you already made, no duplicate, and captured messages wear a small badge so you can see what is already handled. Need to pass it on? Assign it to a teammate from the same button, or ask to be notified as it moves.

It reads the page, not your mailbox

Connecting takes one tap, with no password or token to copy anywhere. And the button reads the email straight off the page in front of you. There is no Gmail API, no Google permissions to grant, and no mailbox access handed over. It sees the email you are looking at, and nothing else.

Your inbox is not your task list. It is just where tasks arrive.

The inbox goes quiet

Run that Thursday email again. It arrives, you click once, and it is a task with Thursday already on it and a link back to the thread. It stops being a reminder you have to keep re-reading and becomes a thing on your actual list, in the actual order it is due. The inbox goes back to being mail, and the work goes where the work lives.

Add UnaTask to Chrome

By the time you sit down, two of the five are gone. The other three survive as one enormous note that reads like a run on sentence, which you will decode later, badly, and split into real tasks that never quite match what you meant.

So do the natural thing instead. Tap the mic and talk, in whatever order it comes, and let the ramble become a list.

One breath in, separate tasks out

You say it all in one go, and it comes back as a tidy set of separate tasks, not one blob. Each one gets the details you mentioned: who it is for, when it is due, how urgent it is, which project it belongs to, and even the one that has to wait on another. You glance over the rows, fix anything that landed wrong, add one it missed, and create them all in a single click.

Your voice stays on your device

The speech to text happens right in your browser. The recording of your voice is never uploaded anywhere, and the model that does the listening loads once and is kept by your browser after that, so every capture from then on starts the moment you tap the mic. Only the plain text of what you said goes on to become tasks. The convenience of talking, with the privacy of a notebook.

Capture at the speed of talking. Keep it as private as a notebook.

The same walk, nothing dropped

Run the walk again. You talk for twenty seconds, drop the phone back in your pocket, and by the time you sit down there is a clean list waiting: five tasks, each assigned, dated and sorted, ready to act on. Nothing decoded, nothing lost between the thought and the list. Open voice capture from your dashboard, or from inside a project, and just say what needs doing.

Capturing a task should cost less than having the task. When it costs more, you stop capturing, and the small things live in your head or in a chat message until they quietly fall out of both.

So on the timeline there is no form. Click the empty space on the day you mean, and a single line opens up. Type the task the way you would say it. Send the deck to Marco Thursday, mark it high. Then press Enter.

It reads what you meant

As you type, it picks the meaning out of your sentence and shows it back to you as little chips. Thursday becomes a date. Marco becomes the person, matched to your team. High becomes the priority. You see exactly what it understood before you commit, so there is no guessing and no surprise. Nothing to correct later because you can see it land as you write.

Press Enter and the task is born already in the right place, on the day you clicked, assigned to the right person, at the priority you set. If you need to change anything else, click the card and everything is there. But most of the time you do not, because the sentence already said it all.

The task should cost less than the thought behind it.

This is the same quick capture you already have on your home screen, brought onto the canvas so your planning never has to pause for paperwork. Think of a task, type the sentence, and get back to the plan. The friction that used to eat your small ideas is simply not there.

What the Gantt gets right, and wrong

The Gantt chart understands time. Tasks are bars on a calendar, longer work looks longer, and you can see the shape of a month at a glance. That part is great. The trouble is that a Gantt is built like a spreadsheet, so the moment reality changes it fights you. One task slips and you are dragging rows and retyping dates, and the links between tasks, if the tool has them at all, are buried in a dialog three clicks deep. It shows you time beautifully and then punishes you for time moving.

What the graph gets right, and wrong

The dependency graph understands relationships. Every task is a node, every link is an arrow, and you can finally see the shape of who is waiting on whom. That part is great too. But a graph floats in no particular calendar. The nodes sit wherever the layout put them, so a task due tomorrow and a task due next month look identical, and the one question everyone actually asks, when will this be done, has no answer on the screen. It shows you order and forgets time.

So you are stuck choosing. Take the Gantt and get time without flexibility. Take the graph and get relationships without a calendar. Most teams end up keeping both, in two tools, which is its own quiet tax.

The synthesis

We did not want to pick a side, so we built the thing in the middle. Tasks are cards, like nodes on a graph, and you draw dependencies by pulling a wire from one to another. But the cards are not floating in nowhere. They live on a real date axis, so where a card sits is when it happens, and how wide it is, is how long it takes. Time and relationships, on the same surface, at the same time.

Two rules keep it honest. You cannot draw a loop, because a plan where A waits for B waits for A is not a plan, it is a paradox, so the canvas refuses it. And a blocker can never end after the task it blocks begins, so when you stretch or move something, everything downstream slides to keep that true. The graph gives you the links. The axis gives you the calendar. The rules keep the two agreeing with each other.

The best tool is often the one that stops making you choose.

We are not claiming to have reinvented planning. Gantts and graphs both got something right, and we borrowed the good half of each. The point was never to add another view to argue about. It was to put time and dependencies in one place, so the plan tells the whole truth instead of half of it.

So a lot of the time we skip it. We start doing tasks and hope the order works itself out as we go. Sometimes it does. More often two people build on top of something that was not ready yet, and the plan you never wrote reveals itself the hard way, in a week you cannot get back.

Here is a version that takes about ten minutes and leaves you with a real plan, not a wish list. Open any project and go to the Dependencies tab. You are looking at a timeline: dates run left to right, and every task is a card you can move.

1. Jot the tasks down by typing them

Do not build a structure first. Click any empty spot on the timeline and type the task the way you would say it out loud. Draft the brief tomorrow, assign it to Sofia, mark it high. It reads the date, the person and the priority as you type, shows you what it understood, and drops the card where you clicked. Do it again for the next task, and the next. Order does not matter yet. You are just getting the work out of your head.

2. Drag them into rough time

Now grab the cards and slide them along the axis to roughly when each one happens. Early things to the left, later things to the right. You are not being precise, you are sketching. Ten seconds of dragging and the shape of the project is already on the screen.

3. Pull the wires

This is the part that turns a pile of tasks into a plan. Pull from one card toward the task it depends on, and a line appears between them. This finishes before that starts. Do it for the handful of links that really matter, the ones where someone is waiting on someone else. If you try to draw a loop, it politely refuses, so you cannot tie the plan in a knot by accident.

4. Set durations, then Recompact

Drag the left or right edge of a card to say how long the work takes, so a two day task and a two week task look like what they are. When it all feels a little loose, click Recompact once. Every task slides back against the thing it was waiting on, the gaps close, and you get the tightest honest version of the plan.

A plan is just the work, in the order it actually happens.

Ten minutes later

Look at what you have. Real dates. Honest dependencies. A picture the whole team can read in a glance, where you can already see the week that is going to be tight and the person who is going to be buried. You did not fill in a single form to get here.

Planning was never the chore. The paperwork around planning was, and we took it out. Open a project, give it ten minutes on the timeline, and let the plan carry the order so you do not have to hold it in your head anymore.

This is how projects slip. Not with a bang, but with a small silence between a task and the thing waiting on it. Nobody was careless. The dependency was real, everybody sort of knew it, and still it lived in someone’s head instead of somewhere you could point at. By the time it surfaces the calendar has already moved, and the standup gets a little quieter than usual.

So we built a place where those two facts meet. There is a new Dependencies tab in every project, and it lays your tasks out on a timeline.

What it looks like

Each task is a card, floating on a date axis. Where a card sits, left to right, is when it happens. The lines between cards are dependencies: this one has to finish before that one can start. You draw one by pulling from a card toward the task it depends on, and the link appears.

Drag a card and it moves in time. Drag its edges and it takes longer or shorter, right there on the axis, so a two day task and a two week task look like what they are. It reads like a plan because it is one, not a list pretending to be a schedule.

When the plan changes, everything downstream moves

Here is the part we are proud of. Stretch a task so it runs a few days longer, and everything that depends on it slides forward on its own. You do not chase the knock on effects, the timeline does. When you have trimmed things back down and want the plan tight again, one button, Recompact, pulls every task back against the thing it was waiting on.

And when a plan does not add up, you see it. If a task that blocks another one ends after that other one is meant to start, the line between them turns red. The hidden delay stops being hidden. It is a red line pointing at the exact place the week is about to break, a week before it breaks.

Add a task by just typing it

You do not fill in a form to get here. Click any empty spot on the timeline and type the task the way you would say it. Draft homepage tomorrow, assign it to Sofia, mark it high. It reads the date, the person and the priority as you write, shows you what it understood, and drops the task exactly where you clicked. Click any card later and you can change everything about it, status, people, dates, estimate, without ever leaving the canvas.

A plan you can see is a plan you can trust.

The same Tuesday, a week earlier

Now run that Tuesday again. A week before the designer pings you, the line between the API and her screen is already red on the timeline. You move one of them a few days, the red goes away, and the conversation you were going to have on Tuesday simply never needs to happen.

That is the whole idea. Dependencies were always there in your projects, quietly deciding what could happen and when. We just put them somewhere you can see them, on the same timeline as the work, so the plan stays honest and the surprises get boring. Open any project, tab over to Dependencies, and pull your first wire.

That is the tax on changing your mind, and it is why plans go stale. Not because people stop planning, but because keeping the plan honest costs more than most weeks can spare. So the plan drifts from reality, and after a while nobody trusts the dates on it, which means the plan has quietly stopped being a plan.

On the timeline, changing your mind is one gesture. Grab the right edge of the design task and drag it three days longer. As you drag, everything that depends on it moves. The build slides forward to stay behind the design. The review slides to stay behind the build. The launch follows. You are not updating a plan, you are watching it rearrange itself to stay true.

The cascade

The rule underneath it is simple and strict: a blocker is never allowed to end after the thing it blocks begins. So when you stretch one task into another one’s space, the software pushes the dependent forward just enough to keep that promise, then does the same for whatever depends on that, all the way down the chain. You move one card. The knock on effects move themselves.

The view keeps up

If the drag runs past the edge of the screen, the timeline scrolls with you, so you are never dragging blind into the void. And when the dust settles and you want the plan pulled tight again, one button, Recompact, closes the gaps and snaps every task back against the thing it was waiting on.

A plan that maintains itself is a plan people keep looking at.

The best part is the part you stop doing

Run the slip again. The design takes three more days, you drag one edge, and the rest of the plan catches up in a second. No afternoon of hand editing, no dates left half updated, no standup where two people are working from different versions of the truth.

This is the whole reason we built the interaction the way we did. A plan is only worth keeping if keeping it is nearly free. Make the change once, let the timeline carry the consequences, and get back to the actual work.

The real problem is not the people, it is where the plan lives. On a team that size the dependencies are all real and all invisible, held in five different heads that each remember a slightly different version. The designer thinks the copy is coming Tuesday. The engineer thinks the design is coming Tuesday. Both are planning around the other, neither can see the other’s plan, and the collision only becomes visible on the day it happens.

Before: a mystery everyone half remembered

Standups were a lot of reconstructing. Who is this waiting on again, is that still blocked, I thought you had that. Half the meeting went to rebuilding a shared picture of the week that fell apart again the moment everyone walked away. Delivery dates were guesses, because a date is only as good as your view of what stands between you and it.

The change: one picture, shared

The shift is almost boringly simple. The dependencies stop living in five heads and start living on one timeline that everyone can see. Who waits for whom is a set of wires between cards. When something is going to clash, the wire between the two tasks turns red, in front of the whole team, a week before it would have blown up in a standup.

The moment it pays for itself

The turning point is not a feature, it is a Monday. Someone opens the project, sees a red wire between the design and the build, and moves one task two days before either person had even noticed the problem. The argument that would have happened on Thursday never gets scheduled. That is the whole return: a conflict caught while it is still just a small adjustment, instead of a delay everyone has to absorb.

You cannot argue about a plan you can both see. You just fix it.

After: delivery you can actually promise

Once the dependencies are visible, the tense standups get shorter and quieter, because there is nothing left to reconstruct. The dates get more honest, because everyone is reading them off the same picture. And when a client asks when it will be done, the answer stops being a hopeful guess and starts being something you can point at.

None of this asks the team to work harder or care more. They already did both. It just takes the plan out of five separate heads and puts it somewhere everyone can stand and look at together. Open a project, draw the dependencies you have all been carrying, and let the timeline hold them for you.

This is what lists do to you. A list is very good at telling you what exists and very bad at telling you what collides. The blocker sits on one line with a date. The task waiting on it sits on another line with an earlier date. Both look fine on their own. The conflict lives in the gap between them, where nobody is looking, and a list has no way to show you a gap.

So we made the gap visible. When you lay your tasks on a timeline and draw the dependencies between them, the software can do the one bit of arithmetic that matters: does this blocker actually finish before the thing it blocks is meant to begin?

The red wire

When the answer is no, the line between the two tasks turns red. That is it. No report to run, no status to read, no meeting to schedule. A task that ends after its dependent is due draws a red wire straight to the place the plan is about to break. The hidden delay stops being hidden, and it does it while there is still time to move.

Fixing it, in three moves

A red wire is not a scolding, it is a choice. You have three honest ways to clear it, and you can see each one land on the timeline as you try it.

• Move the dependent task later, so it starts after its blocker really finishes.
• Shorten the blocker, if the work can be trimmed, so it ends in time.
• Cut the link, if it turns out one did not truly need the other after all.

A conflict you can see on Monday is a conversation, not a crisis.

The same Friday, without the surprise

Run that week again. On Monday the wire between the two tasks is already red. You nudge one of them two days, the red clears, and the Thursday where everything fell over simply never arrives. The deadline that felt safe actually was, because you could see the one place it was not.

Delays do not have to be dramatic to be expensive. Most of them are quiet, small silences between a task and the thing waiting on it. Put the work on a timeline, let the conflicts turn red, and the surprises get boring. Boring is exactly what you want a deadline to be.

In-app and email notifications quietly assume you’re sitting in front of the tool. Most of the time that’s a fair bet, and for most reminders it’s plenty. But the deadlines that hurt to miss have a way of falling when you’re not at your desk, on the move, between things, deep in something else. The reminder fires perfectly into a channel you aren’t watching, and a perfect reminder nobody sees is just a quiet failure.

A text, for the ones that matter

For the reminders you genuinely can’t miss, UnaTask can send a text. A deadline approaching, a meeting about to start, the thing you flagged as important reaches your phone the way a message from a person would, in the place you check without thinking, even when you’re nowhere near the app.

• Get a text for the deadlines and reminders that actually matter, not for everything.
• It lands in your pocket, the one channel you check on instinct, desk or no desk.
• It rides on the reminders you already set, just delivered somewhere harder to ignore.
• Keep the noisy stuff in app and email, and reserve the text for the things worth a buzz.

The restraint is the point. A text that fires for every trivial task trains you to ignore texts, which defeats the whole purpose. So this is for the short list of things that warrant interrupting your day, the way a calendar alert for a flight is welcome and a calendar alert for everything is just noise you mute. Used sparingly, a text is the most reliable nudge there is.

Same deadline, different ending. Tariq is out, away from the badge and the buried email, and his phone buzzes with a short text: the thing is due in an hour. He handles it from where he’s standing. The reminder finally reached him, not because he got more disciplined about checking, but because it showed up where he was already looking.

A reminder is only as good as the channel it lands in. For the few things you truly can’t miss, send it to the pocket, and leave the rest to the quieter channels.

Option one: you stop, open your task app, find the right project, type it out, set a date, come back, and try to remember where your head was. Option two: you tell yourself you’ll remember, and you don’t, and Thursday arrives without the numbers. Neither option is good, and you make some version of this choice a dozen times a day.

The task should come to you

The work that goes missing is almost never forgotten on purpose. It’s the work you couldn’t capture without paying a tax in focus. So the fix is to drop the tax. The task should be created where the request already lives, in one motion, without you leaving the thing you were doing.

That’s what capturing from your real tools means in practice. Not another inbox to check. A way to turn whatever just landed into a task on your calendar, then get straight back to work.

Three places it happens

• Gmail: hover an email and turn it into a task in one click, deadline read straight from the message, no retyping.
• Slack and Discord: turn any message into a task without leaving the channel, assignee and due date right there.
• Your voice: say the task out loud and let it land on the calendar, for the ideas that arrive when your hands are busy.

Each one removes the same tax: the cost of switching apps just to remember something. The request becomes a task in the place you already were, and your attention never has to leave the room.

The same forty minutes, kept

Back to that Slack message. This time you turn it into a task without opening anything, see it drop onto Thursday morning, and you’re reading the next line of your own work before the interruption even registered as one. The numbers go out on time. Your focus block survives. Nothing slipped, and nothing cost you the thread.

The best place to capture a task is the place the work already is. Every app you have to open to remember something is a small tax on the work you opened nothing to do.

The alternative isn’t a heavy productivity system you have to tend like a houseplant. It’s a light rhythm, about fifteen minutes total across the week, that trades the fog for a shape. Here’s the version we actually use.

Friday: a five minute close

Before you log off, look at what didn’t get done and be honest about it. Move the still important things to real days next week. Let the no longer important things die without ceremony. You’re not planning yet, you’re just clearing the fog so Monday you doesn’t inherit a mess.

Monday: a ten minute plan

• Pull the week’s real priorities into one place, the few things that would make the week a win.
• Drag them onto the calendar, hard work into mornings, shallow work batched into afternoons.
• Leave gaps on purpose, because the week will bring things you can’t see yet.
• Glance at the team’s week so your plan and theirs don’t collide on Wednesday.

Ten minutes, and the week stops being a fog. You don’t have to follow it perfectly. You just have to have it, so that when something lands you’re adjusting a plan instead of inventing one.

Daily: work the block, not the list

Each morning, don’t reread the whole list and feel the weight of it. Look at the next block, do that one thing, and let the rest stay out of view until its slot comes. When something runs long or a fire starts, reschedule the bumped block to a real new time instead of deleting it and pretending. The plan stays honest because you keep telling it the truth.

The week, with a shape

By Friday you’re back at the five minute close, and it’s a calmer one, because the week didn’t happen to you. You can see what got done and where the time went, and the dread that used to live in Sunday has somewhere to go: into a plan that took fifteen minutes and gave back the whole week.

Fifteen minutes of planning is cheaper than five days of scrambling. The plan doesn’t have to be perfect. It just has to exist, so you spend the week adjusting instead of inventing.

That’s the quiet flaw in most shared calendars. They show meetings as real and everything else as available. So the work that needs the most protection is exactly the work that looks the most bookable, and it gets booked over, again and again, by good people reading an honest gap.

Make the focus visible as real

The change is small and it fixes the whole thing: put your focus on the calendar as a real block, and let the team see it. Now the morning you protected isn’t white space. It’s clearly time that’s spoken for, and the person looking for a slot sees it and moves on to the actual gap.

When everyone’s blocks are visible, the calendar stops being a list of meetings and becomes a picture of the team’s real week. You can see who’s heads down and shouldn’t be pinged, who’s free, and where the shared openings actually are.

What that looks like day to day

• Overlay the team’s busy and free time in one view, instead of opening six calendars.
• Spot the real gaps for a meeting, the slots that are free for everyone, not just free for you.
• See who’s in deep work right now, so a “quick question” waits twenty minutes instead of breaking an hour.
• Book into the seams, so meetings cluster and focus stays in long unbroken stretches.

It’s the same calendar everyone already lives in, doing one extra thing: treating attention as something worth protecting, not just something to schedule around.

The same Wednesday, defended

This time the morning is a visible block. The invite that would have landed on it lands in the open slot at two instead, no conversation needed, no awkward decline. You do the hard thing in the quiet you set aside, and the meeting still happens, just where it fits. Nobody had to fight for the morning. The calendar did it for you.

A good shared calendar doesn’t just schedule the team’s time. It protects the team’s attention, by making the difference between busy and bookable something everyone can see.

That’s the thing nobody tells you. A block only you can see is just personal optimism. Time blocking gets good, the kind of good you don’t abandon, when the team can see the time too. Here’s how to set that up. It takes about twenty minutes and you only do it once.

The twenty minutes

• Make a project for the real work of this week, not a someday backlog. One project, the things that actually matter now.
• Add the tasks to it as you’d say them out loud. Don’t overthink the wording, you can fix it later.
• Drag each task onto a slot on your calendar. Give the hard ones a morning, batch the small ones into one afternoon block.
• Leave your blocks visible to the team, not private. This is the step that does all the work.
• Open the team view and look at the overlay: who’s heads down, who’s free, where the shared gaps are.

That’s it. You now have a week with a shape, and so does everyone who can see it. The setup cost you twenty minutes. It will save that back by Tuesday.

Why visible time changes the room

When blocks are shared, three annoying things stop happening. Meetings stop landing on deep work, because the person booking can see the block and chooses the open gap instead. Standups get shorter, because the plan is already on the calendar and nobody has to narrate it. And the awful “who’s actually got bandwidth this week” conversation turns into a glance, because the answer is right there in the overlay.

None of this requires a process document or a ritual. It’s just the difference between time you can see and time you can’t. Once the team can see it, protecting it becomes the default instead of a fight.

A few honest tips

• Block focus first, meetings second. Defend the mornings before the calendar fills them for you.
• Leave slack on purpose. A day blocked to the minute breaks the first time something runs long, and something always runs long.
• When you move a block, move it honestly to a real new slot. Don’t just delete it and pretend the work vanished.

Time blocking alone is a habit you fight to keep. Time blocking together is just how the team sees the week. The second one sticks, because it stops being willpower and starts being visible.

What each one is good at, and blind to

• A pure list app, like Todoist, is wonderful at capturing and sorting. It will hold a thousand tasks beautifully and never once tell you that today only fits six.
• A project tool, like Asana, is built for who owns what across a team. It tracks the work, but it lives a world away from the hours in your day, so the plan and the calendar never actually meet.
• A calendar app, like Google Calendar, is honest about time, but it only knows meetings. Your real work, the solo focus that fills most of a week, is invisible to it.
• An auto scheduler, like Motion, does put tasks on time, which is the right instinct. The risk is a plan the algorithm owns, that you stop trusting the moment it shuffles your day for reasons you can’t see.

None of these are bad tools. They’re just each holding one half of the problem. The list half knows what. The calendar half knows when. As long as those halves live in different apps, you’re the integration, copying between them by hand and losing a little in every trip.

Time blocking is the admission that you need both

Time blocking isn’t a fifth competing app. It’s the simple idea that a task and a time belong together, in one place, so a plan is something you can see at a glance instead of assemble in your head. Your tasks sit on your calendar. The day pushes back when you overload it. The focus you need is a real block, not a hopeful gap.

And because it’s your hand doing the blocking, not an algorithm’s, you trust the plan, because you made it. The tool can suggest, it can lay out a first draft, but the final say is yours, which is exactly why you’ll actually follow it.

The unit that matters

Here’s the quiet shift under all of it. A list measures work in checkboxes, and a checkbox has no size. The honest unit of a working week isn’t the task, it’s the hour. When you plan in hours, the math stops lying, the day stops overpromising, and the week ends closer to where you meant it to.

The list knows what. The calendar knows when. Time blocking is just refusing to keep them in separate apps, and planning your week in hours instead of checkboxes.

By Friday at six, six of the eighteen are crossed off. Four new ones arrived. The list is longer than when you started, and somehow that feels like your fault. It isn’t. The list lied to you, gently, the way it lies to everyone, by pretending that eighteen things and one day are the same size.

A list answers “what”, never “when”

A to-do list is a stack of intentions with no sense of time. It will happily hold forty items for a Tuesday that fits six, and it will never once warn you. It can’t. It has no idea how long anything takes, or how many hours you actually have after the two meetings, the lunch you’ll skip, and the half hour that always disappears into other people’s urgencies.

So you spend the week reacting to the longest, loudest item instead of the right one, and the quiet important work slides to tomorrow. Tomorrow’s list inherits it, plus interest. The guilt builds, and the guilt is the cruelest part, because you were never overcommitted on purpose. You just couldn’t see the gap between the plan and the day.

The missing dimension is time

The fix isn’t a better way to sort the list. It’s adding the one thing the list refuses to show you: when. The moment you drag a task onto a real slot on a real calendar, the day pushes back. Three deep tasks and you’re already at four in the afternoon. There it is, in front of you, before the week starts instead of after it ends.

That pushback feels like bad news for about a second, and then it feels like relief. You’re not failing to finish eighteen things. You’re finishing the six that fit, on purpose, and the other twelve have honest homes on real days instead of haunting a list.

The same Monday, told the truth

Picture Monday again, but now the eighteen are on a calendar. The two meetings are blocks, so you can see the actual hours left. The deep work has a morning. The small stuff is batched into a single afternoon slot. Six things live on today because six is what today holds. The rest are spread across the week, each with a time, each safe to ignore until then.

Friday arrives. The list is shorter, not longer, and you can say where the time went, because you decided in advance. That’s the whole difference. Not more discipline. Just a plan that knew what a day was.

A list is a wish. A plan has a time on it. The day was always going to win the argument, so let it have the argument before the week starts, not after.

A booking link solves this when it’s an outsider picking a time. But for the person you work with every day, sending them a link feels oddly formal, so you fall back to the manual dance instead: comparing calendars in your head, negotiating slots over chat, and doing the event setup yourself once you finally agree. It’s small, and you do it ten times a week, which is exactly how small things become a real tax.

Ask in one line, confirm in one click

Say what you want: “book the first free slot with Serena this week.” UnaTask reads both calendars, your synced Google availability and hers inside UnaTask, finds the earliest time you’re both genuinely free, and shows you the proposed meeting. You look at it, confirm, and it creates the event with a video link and sends the invite.

• It checks real availability on both sides, around meetings and protected focus alike.
• You get a preview first, never a surprise meeting dropped on your calendar.
• Confirm and it sets up the event, the video link, and the invite in one motion.
• No three-option message, no waiting, no manual event creation after you agree.

The preview-then-confirm step is what makes it feel safe instead of presumptuous. It doesn’t silently grab a slot and tell you afterward. It proposes the obvious answer, the first time you’re both free, and lets you say yes. You keep the judgment call, you just skip the tedious part that led up to it: the comparing, the messaging, the waiting, the setup.

Now Omar types one line, sees “Tuesday 11:00, both free, Meet link attached,” and confirms. Serena gets an invite to a time that was genuinely open for both of them, with the video call already on it. The thirty minute meeting took about five seconds to arrange, and the ten minutes of calendar admin simply didn’t happen.

Scheduling with a colleague shouldn’t need a link or a negotiation. State who and roughly when, let the calendars do the matching, and keep the final yes for yourself.

A personal booking link is a solved problem. A team booking link raises two new questions a single link can’t answer on its own. When a call could be handled by any of several people, who actually gets it, and how do you keep it fair instead of dumping it all on whoever owns the link? And for the other kind of meeting, the one that genuinely needs three specific people in the room, how do you offer only the times when all three are free? Send a normal link and you get either one exhausted host or a slot that half the required people can’t make.

Round robin: spread the calls

A round robin link points at a pool of hosts instead of one person. An incoming booking goes to whoever in the pool is free, and the load spreads across the team automatically. You can weight the pool, so a host who should take more calls gets a bigger share, and one who should take fewer gets a smaller one, or none while still staying on the team.

• Bookings land on whichever host is genuinely free, not always the same person.
• Weighted shares let you tune who carries more and who carries less.
• Set a host’s share to zero to keep them on the team but off the rotation for now.
• Each booking records who it was assigned to, so the call has a real owner.

Collective: get everyone in the room

A collective link is the opposite instinct. Instead of routing a call to one of several people, it offers only the slots when all the required hosts are free at once. The guest sees the times that work for the whole group, picks one, and everyone who needs to be there is already accounted for, no cross checking calendars by hand.

The two modes answer the two questions cleanly. Round robin is for interchangeable hosts and asks who should take this, fairly. Collective is for required co-hosts and asks when is everyone free, exactly. Same booking link idea your guests already understand, pointed at a team instead of a person, and still respecting everybody’s real calendar and protected focus underneath.

Now the demo link is a round robin across all three reps. The next prospect who books lands on whoever’s actually open, weighted so Raul finally gets a lighter share while the other two pick up the slack they were always able to handle. And when the team needs a call with all three plus the lead, the collective link offers only the windows where every one of them is free. Nobody’s buried, nobody’s idle, and the prospect just sees a link that works.

A personal link protects one calendar. A team link has a harder job: spreading the work fairly, or gathering the right people, without anyone doing the matching by hand.

So she does what most people do with a clear plan and no time to lay it out: she keeps it in her head and starts swinging. The proposal gets forty minutes before a “quick question” takes the rest of the morning, the prep happens in the elevator, and the day she could see at 8:40 is gone by 11, not because the plan was wrong, but because it never made it onto the hours.

The gap is never knowing what to do. It’s the friction between knowing it and placing it. A plan in your head is weightless and easy to abandon. A plan on the calendar pushes back, defends itself, and survives the day, but only if laying it out is cheaper than just winging it.

Say the plan, see it placed

Tell UnaTask what you want in plain words, “two hours on the proposal this morning, prep before the 2pm, batch the small stuff after,” and it drafts an actual schedule. It already knows your meetings and the focus you’ve protected, so it lays the work into the hours that are genuinely free and explains why each block landed where it did.

• Plan in plain language, no dragging six blocks by hand.
• It works around your real calendar and your focus time, never on top of them.
• Every proposal comes with its reasoning, so you can see why a block sits where it does.
• It’s a draft, not a verdict: approve it, nudge a block, or throw one back.

That last point is the whole posture of it. The schedule is a first draft you own, not a plan the algorithm imposes and reshuffles behind your back. The heuristic owns the slots, you own the final say, which is exactly why you’ll trust the day enough to actually follow it. A plan you approved beats a plan you were handed, every time.

Same 8:40, different morning. Yuki types the day she could already see, glances at the draft, moves one block ten minutes, and approves it. The proposal has its two hours, the prep has a real slot before the 2pm, and the small stuff is boxed into one afternoon block instead of leaking across all of them. She spent thirty seconds laying out the day instead of losing it.

The hard part was never deciding what to do. It was placing it before the day placed itself. Say the plan, let the calendar draft it, and keep the final word.

Ideas don’t wait for you to be at a keyboard. They show up mid walk, mid commute, mid washing up, exactly when typing six fields into a form is impossible. So the richest thinking of the day, the loose, connected, three-things-at-once kind, is precisely the thinking most likely to evaporate before it’s written down. Not because it wasn’t good. Because your hands were busy.

Talk first, sort later

Hit the mic and just talk. Ramble through everything on your mind in one go, no structure required, and UnaTask turns the dictation into separate, clean tasks. One messy paragraph of speech comes back as a tidy list you can glance over, edit, and drop onto your week.

• Dictate freely, one stream of thought, no need to pause between items.
• It splits the ramble into distinct tasks, not one giant unreadable note.
• Review the list before anything is saved, so you stay in control of what lands.
• Capture three things in the time it used to take to half-remember one.

The splitting is the quiet trick. Voice notes everywhere else give you a recording you have to listen to again later, which is just moving the work to future you, who is also busy. Here the talking is the capture and the sorting both. You speak the mess, you get back the structure, and the only thing left to do is approve it.

Same walk to the station. Diego taps the mic, says all three things in one breath without breaking stride, and pockets the phone. By the time he sits down on the train, three separate tasks are waiting for a glance: the supplier call, the pricing slide due Thursday, the new-hire follow up. None of them survived on memory. All of them survived because saying them was easier than holding them.

The thought that arrives when your hands are full is usually the one worth keeping. Let your voice do the capture, and let the tool do the sorting.

A lot of meetings are mixed company. Your team is in the room, sure, but so is a client, a candidate, a contractor, a partner, people who will never have a login to your workspace and shouldn’t need one. When a tool can only invite its own members, it forces you to split every external meeting across two systems, double the setup and double the chance someone gets the wrong time or no invite at all.

Add a guest by email, full stop

When you create an event or a call, add guests by email right there, teammates and outsiders alike. The people outside your workspace get a proper email invitation to the event, with the details and the time, so everyone who needs to be in the room gets asked from the same place, in the same motion.

• Add anyone by email when you create an event, no workspace account required.
• Outside guests receive a real invitation email with the event details.
• One event, one source of truth, instead of the same meeting set up twice.
• Mix internal and external attendees on the same call without leaving the tool.

The quiet win is that there’s only ever one version of the meeting. When you invite outsiders from a second calendar, you create two records that drift, different times after a reschedule, someone missing from one list. Inviting everyone from a single event means the meeting has one home, and a change to it reaches everyone, member or guest, the same way.

Now Priyanka’s kickoff is one event. She adds her teammates and types the client’s and the freelancer’s emails into the same guest field, and they all get invited from the same place. No second calendar, no two slightly different versions of the same call, no outside collaborator left off because the tool only spoke to its own members.

The people in a meeting rarely all share your tools. An event worth setting up should be able to invite anyone, by the one address everybody already has.

Recurring tasks are where a lot of task managers quietly fail. Either the recurrence is decorative, a label that resets and never really lands on a day, so you stop trusting it. Or it’s too literal, spawning every future instance up front, so the one thing you have to do this week is drowning in a forecast of things you don’t have to think about yet. Both versions make the calm list anxious, which is the opposite of the point.

Only the next one, every time

A recurring task in UnaTask is a series, and the series only ever shows you the next occurrence. Finish this Monday’s report and the next Monday’s appears, dated correctly, not a moment sooner. The future is handled, but it stays out of sight until it’s actually your problem.

• See only the next occurrence, so the list stays a list, not a forecast.
• Edit just this one or the whole series, whichever you meant.
• Skip an occurrence and it jumps cleanly to the next real date, no orphaned copy left behind.
• Dates are computed properly, fixed schedules and “every two weeks” alike, so the next one always lands where it should.

The this-one-versus-all distinction is the part you feel most. Move a single week’s report because of a holiday and the series doesn’t flinch. Change the time you do it every week and one edit updates the pattern. You never have to choose between fixing today and fixing forever by accident, because the tool knows the difference and asks.

Now Hana’s weekly report just shows up on Monday, alone, on the day it belongs to. The eleven phantom copies are gone. When she takes a week off she skips one and the rhythm picks back up on the right date without a stranded checkbox to clean up. The chore that used to either nag her or hide from her now simply arrives, does its job, and leaves.

A recurring task should feel like a heartbeat, not a hoard. One at a time, on the right day, with the future kept quietly out of view until it’s due.

Workspaces remember their members and forget everyone else, which is backwards, because the everyone-else is most of who you actually deal with. Clients, freelancers, partners, the guest from last month’s call, they pass through your work constantly and leave no trace the tool can reuse. So you retype the same handful of external addresses forever, and every retype is a fresh chance to fat-finger a letter and send an invite into the void.

The directory builds itself

UnaTask keeps a shared contacts directory for the workspace, and it fills itself in. The people on your team are there, and so is everyone you’ve already worked with: past guests on events, collaborators you’ve invited before. There’s no list to maintain by hand. The history you’ve already made is the address book.

• Contacts assemble automatically from members and people you’ve worked with before.
• Email fields autocomplete, so you pick a name instead of retyping an address.
• It’s shared across the workspace, so a teammate’s past guest is a contact you can reach too.
• Nothing to maintain: working with someone is what adds them.

The shared part does quiet work for a team. The client a colleague dealt with last quarter isn’t locked inside their personal memory, they’re a contact the whole workspace can reach. So when you cover for someone, or pick up an account they started, the people are already there, no “can you send me their email” round trip required.

Now Marisol starts typing the client’s name and it completes, address and all, because she’s worked with him before and the directory noticed. The inbox archaeology is gone, the typo risk with it. The address book she never built is just there, made entirely out of the work she’d already done.

You shouldn’t have to maintain a list of the people you obviously know. Working with someone should be enough to remember them, for you and the whole team.

A fast capture habit has a failure mode nobody warns you about. The faster you catch things, the bigger the undifferentiated pile gets, and a pile is just as paralyzing as a forgotten task, only louder. Everything caught and nothing decided is its own kind of stuck. The work isn’t lost anymore. It’s just sitting there, seventy items deep, with no sense of what’s today and what’s someday.

Triage first, then plan the week

The inbox is where new tasks land to be sorted, not stored. You move through triage lanes and make one small decision per task, what is this and roughly when, then it leaves the pile. From there, the week planner lays your days out side by side and you drag each task onto the day you’ll actually do it.

• Triage lanes turn a wall of tasks into a short series of one-second decisions.
• Drag a task onto a day and that day becomes its planned start, separate from its hard deadline.
• Plan the week at a glance, every day visible at once, instead of guessing from a flat list.
• The pile empties as you go, so an empty inbox actually means handled, not hidden.

The split between planned day and deadline is the part that quietly fixes everything. A deadline is when a thing is due. A planned day is when you intend to start it, which is usually not the same and definitely shouldn’t be the day before it’s due. Dragging a task onto Wednesday says “I’ll begin this Wednesday,” so the work spreads across the week on purpose instead of stacking up against its due dates in one terrible Friday.

Now Noor’s seventy things don’t live in one shouting list. New stuff lands in the inbox, she triages the pile down in a couple of minutes, and the week planner shows her a real week: this on Tuesday, that on Thursday, the heavy thing started early instead of cramming. Capture catches the work. Triage decides it. The planner gives it a home. The pile stops being a threat and becomes a plan.

Catching every task is only half the habit. The other half is deciding what each one is and when it happens, before the pile decides for you.

Chasing work across a team is mostly an awkwardness problem dressed up as a process problem. The two obvious moves both cost something. Nag in chat and you feel like a manager you didn’t mean to become, and the message arrives without the task attached anyway. Say nothing and the thing quietly slips, your work with it. Most people pick silence, because it feels more polite, and silence is how deadlines die.

One tap, one polite ping

Open the task you’re waiting on and send a nudge. The person it’s assigned to gets a notification and an email, pointing right at the specific task, no message for you to word, no thread to start. It’s a small, neutral “this is waiting on you,” attached to the exact thing it’s about.

• Nudge the assignee of a task you don’t own, straight from the task itself.
• They get an in-app notification and an email, both linked to the exact task.
• There’s a cooldown, so a nudge stays a nudge and never becomes nagging.
• No wording to agonize over, the task speaks for itself.

The cooldown matters more than it looks. It quietly takes the menace out of the feature. You can’t fire ten nudges in a row, so a nudge can never read as harassment, only as a reminder. That single constraint is what lets people use it freely, because everyone knows it’s a gentle tap on the shoulder by design, not a weapon.

Now Lena taps once. Her teammate gets a clear, friendly notification pointed at the exact task, sees it for what it is, an honest “hey, this one’s waiting,” and picks it up. No awkward thread, no passive aggressive silence, no third “any update?” The thing that was stuck moves, and nobody had to feel like the bad guy to move it.

Most stalled work doesn’t need a meeting or a manager. It needs one small, kind reminder, pointed at the right task, that nobody has to feel awkward sending.

Nobody has a good answer, because the time didn’t go anywhere dramatic. It leaked. Fifteen minutes hunting for the decision buried in a chat thread. A task that lived in one tab while the calendar lived in another. Two people doing the same thing because nobody could see who had it. The work was never the problem. The overhead around the work was.

Picture the smallest version of it. A teammate asks, in chat, “can you get the deck to the client before Thursday?” You say sure. The message scrolls away. Thursday arrives with no deck, not because anyone forgot to care, but because “sure” never became anything a person could see. Multiply that by a team and a month, and you have the quiet way good work goes missing.

We’ve been on teams like that. You probably have too. Not bad teams, good people quietly worn down by the friction of staying organized. We built UnaTask because we wanted that friction to disappear, so the week ends with the list shorter and the team less tired.

What we believe

A few convictions shape everything in the product.

• A list is a wish. A plan has a time on it.
• Focus is something the tools should protect, not something you white knuckle alone.
• A team works best when the work is visible: who has what, and who is buried.
• Fewer apps, fewer tabs, fewer “wait, where did we say that?” moments.

Our mission

Help teams spend their hours on the work that matters, and protect the hours they need to do it.

That’s the whole thing. Everything else serves it. If a feature doesn’t give you back time or attention, it doesn’t belong here. That single test has killed more ideas than it has shipped, and the product is better for it.

Why simple is the hard part

It’s easy to add another field, another view, another setting, and end up with software that needs its own onboarding course. We’d rather keep the surface small and the defaults sensible, so the tool fades into the background and the work comes forward. Simple is not the absence of power. It’s power you don’t have to think about.

In practice that means your tasks and your calendar live in one place, so a plan has a real time on it. It means the work shows up where your team already is, in chat, in the inbox, in a meeting, instead of asking everyone to come to it. And it means the focus you set aside for hard work is treated as real, not as the first thing to get booked over.

We’re early, and honest about it. There’s a lot still to build, and we’re building it in the open, shaped by the teams who use it every day. But the Friday we’re aiming for is clear: the good tired kind, where the week’s work is visible, finished, and didn’t cost more than it was worth. If that sounds like the week you’d rather be having, give it a try, and bring the team whenever you’re ready.

A week later, half of it has evaporated. Two of the twelve decisions happened because someone remembered. The other ten are somewhere in Dana’s notes, which are somewhere in a doc nobody has opened since. The meeting was productive. The follow through was not.

This is the meeting tax. The hour in the room is the cheap part. The expensive part is everything that was supposed to happen after it, and the slow leak between “we agreed to do this” and anyone actually doing it. Notes don’t fix it, because a wall of text is not a plan. It’s a wall of text with good intentions.

The meeting writes the list, not you

Invite the UnaTask notetaker to your call. It joins, transcribes, and when the meeting ends it reads the transcript and pulls out the action items: who agreed to do what, by when. The decisions become tasks before Dana has even closed the tab.

• Action items become real tasks, assigned to the person who took them on.
• Deadlines mentioned out loud (“by next Friday”) land as real dates.
• They drop straight into each person’s queue and onto their calendar, so the next step is already waiting.

So when someone says “Leo, can you send the revised quote by Tuesday?”, that line becomes a task on Leo’s list, due Tuesday, without Leo writing anything down or trusting that he’ll remember. Plenty of tools take good meeting notes. The difference here is what happens after: the task manager and the calendar sit right underneath, so the follow up doesn’t need a second app or a copy and paste session. The transcript is still there when you want the exact words. Most days you won’t need it.

It changes the texture of the meeting itself, too. When people know the follow up is automatic, the room spends less time negotiating who writes things down and more time actually deciding. The note taking anxiety, the half listening while you type, the “wait, can you repeat that?”, all of it quietly goes away.

Same kickoff, different week. The call ends, and by the time Dana reaches for a pen the work has already sorted itself: each decision a task, on the right person’s plate, with the date it was promised for. Nobody is the designated note taker. Nobody is the bottleneck. The momentum from the room makes it into the week intact.

A meeting should leave the room as a plan, not as a memory you’re racing to write down before it fades.

Sam reads it. There’s a request in there, and a date: “before the end of next week.” Sam thinks, sincerely, *I’ll deal with this later.* Then archives it, because an empty inbox feels like progress. The request is now gone. So is the date.

This is how work disappears. Not dramatically, tidily. The inbox rewards you for clearing it, and the clearing is exactly what buries the thing you meant to do. A week later the client asks how it’s going, and “it” never started. Nobody dropped the ball on purpose. The ball was just never written down anywhere a person actually looks.

The problem was never Sam’s memory. It was the gap between where the work arrives, the inbox, and where the work lives, the list. Every request has to make that jump by hand, and hands are busy at 4:40 on a Thursday. So we closed the gap.

One click, straight from Gmail

Our Chrome extension puts a small button right where you read your mail. Hover over the client’s email, click, and it becomes a task in UnaTask: the title, a link back to the thread, and a due date if the email mentioned one. Nothing to type.

• No switching tabs, no pasting, no rewording the request yourself.
• Deadlines are parsed from plain language, so “by Friday” becomes an actual date on the task.
• The task keeps a link to the original email, so the full context is one click away when you sit down to do it.

The deadline parsing is the part that feels like a small magic trick. The email says “before the end of next week,” and the task arrives with an actual date attached, not a vague intention. You didn’t open a date picker. You didn’t do the mental arithmetic of what “end of next week” means. It was simply read, the way a colleague would read it.

Same Thursday. Sam reads the client email, clicks once, and watches it land in the list with Friday already attached. Then archives it, guilt free, because this time clearing the inbox erased nothing. The request is waiting for tomorrow morning, next to everything else that’s real. The call starts in nineteen minutes. Sam is, briefly, on top of things.

An inbox is a terrible to do list. It mixes the urgent with the trivial and quietly punishes the wrong habit. The fix isn’t more discipline. It’s a one click bridge from where work shows up to where work gets done.

Time blocking only works if the calendar tells the truth, and most people are quietly running two or three calendars that each tell a different version of it. Work in one, personal in another, the shared team one in a third. Each is honest on its own. Together they lie, because no single view knows everything that has already claimed an hour of your day. So you plan against a calendar that’s missing pieces, and the plan breaks before lunch.

Everything in one place, both ways

Connect your Google Calendars, all of them, and UnaTask shows them together. The sync runs both ways: block time here and it appears there, an event lands there and your free time updates here. There’s no “work me” and “home me” fighting over the same Tuesday. There’s just the day, told straight.

• Connect multiple accounts, not just one.
• Busy is busy: existing events are respected when you plan and when people book you.
• Video links can be generated for the calls you schedule, nothing to paste.

There’s a quieter benefit too. Because the sync goes both ways, the time you block in UnaTask shows up as busy everywhere else, so a colleague glancing at your calendar sees the focus block and books around it. You protect the time once, and it’s protected in every tool that reads your calendar.

And the work and life thing is not a slogan. The dentist, the school pickup, the gym slot you keep skipping because “something came up”, they’re real claims on your hours, and pretending they live in a separate universe from work is exactly why the work plan keeps collapsing. The point isn’t to replace your calendar. It’s to stop you from keeping the real one in your head, the running mental tally of “oh right, I also have that thing.”

Marco blocks his Tuesday again. This time the dentist appointment is already there, in the same view, because the personal calendar is finally in the room with the work one. He blocks around it without thinking, and the two hours he protects are two hours he actually gets. The plan survives contact with the day.

You can’t protect time you can’t see. The first step to a calendar that tells the truth is putting the whole truth in one place.

So she did what everyone does and got a booking link. Share the link, the client picks a slot, done, no more email tennis. It solved the back and forth beautifully. It also, just as beautifully, dropped a sales call at 9am right in the middle of the two hours she’d set aside to do the deep work the client was paying for.

That’s the hidden cost of most booking links. They protect you from email and expose you to interruption. They know when you’re in a meeting, but they have no idea that Tuesday morning was supposed to be sacred. So the calendar fills up, technically conflict free, and the focused hours get quietly eaten one polite booking at a time.

Scheduling that respects your blocks

Because UnaTask already knows your calendar and the time you’ve blocked for focus, your booking link only offers the slots that genuinely work: around your meetings and around the work you’ve protected. Set your availability once, and the link keeps itself honest as your week changes.

• Guests pick a slot, get a confirmation, and can reschedule or cancel themselves.
• Your focus blocks count as busy, so nothing books over them.
• Need a video call? A meeting link is created automatically for each booking, nothing to paste.

The reschedule part matters more than it sounds. When a client moves a call, it moves itself, with a new video link, and your freed up hour reopens for booking automatically. You find out by seeing the updated calendar, not by managing it. And because it’s a Calendly style flow that lives inside the tool where your work already is, a booked call shows up next to your tasks instead of in a separate scheduling silo.

For anyone who sells their focus, this is the whole game. The deep work is the product. An afternoon sliced into three meetings with forty minute gaps isn’t half as productive as a clear block, it’s barely productive at all. Protecting those blocks at the booking layer means you defend them once, automatically, instead of declining invitations one apologetic email at a time.

Now Priya shares one link and forgets about it. Clients book themselves, reschedule themselves, get their own video links. Her mornings stay in one piece because the link knows they’re spoken for. The five email thread is gone, and so is the broken afternoon that used to come with solving it.

A good booking link saves you from email. A great one also saves you from a calendar full of other people’s priorities.

Here’s the lie every to do list tells: that a day is a bucket you can keep adding to. It has no sense of time, so it lets you write nine hours of work onto a six hour day and feel organized doing it. Then reality arrives with its meetings and its interruptions, the list doesn’t shrink the way you imagined, and you end the day feeling behind on a plan that was never physically possible in the first place.

The small habit: give every task a time

The fix is almost embarrassingly simple. Stop writing a list and start building a schedule. Take the tasks that matter and put them on the calendar, as actual blocks of time, in the hours you actually have. Not “write the proposal” floating on a list, but “write the proposal, 9 to 10:30,” sitting in a real slot.

• Block the few things that truly matter first, before the day fills with other people’s requests.
• Be honest about how long things take, then add a little, because you’re optimistic and wrong about this.
• Leave gaps on purpose, for the interruptions you know are coming.

The magic isn’t the calendar, it’s the collision with reality. The moment you try to place nine tasks into six hours of blocks, you can see they don’t fit. So you choose, on purpose, in the morning, instead of having the day choose for you by running out. The plan becomes something a day can actually contain.

This is exactly what UnaTask is built around. Your tasks and your calendar live in the same place, so turning a task into a time block is a small move, not a copy between two apps. The day you planned and the day you’re living are the same screen.

Jonas’s mornings look different now. He doesn’t write nine things and hope. He blocks the three that matter into the hours he has, drops the rest to a real later, and works the schedule instead of the wishlist. The list stopped lying because it stopped being a list. By evening, the plan and the day mostly agree, and that agreement is what “a good day” quietly turns out to be.

A list is a wish. A plan has a time on it. The whole trick is to stop asking what you want to do today and start asking what will actually fit.

Chat is where work gets requested and where it quietly goes to die. The ask was real, the agreement was real, but neither of them is anywhere except a thread that’s now four hundred messages deep. Thursday arrives. The deploy didn’t. Not because anyone dropped it on purpose, but because “yep, on it” lived in a place designed for talking, not for remembering.

Capture it where it’s said

In Slack, use the message shortcut. In Discord, right click, Apps, create a task. Either way the message becomes a task in UnaTask without anyone leaving the conversation, and you set who it’s for and when it’s due right there in chat.

• Pick the assignee and the deadline inline, in a couple of clicks.
• The task links back to the original message, so the context comes with it.
• Nothing gets lost in the gap between “sure, I’ll do it” and actually doing it.

It works just as well when the ask is for someone else. A lead can turn “can someone own the release notes?” into a task assigned to a specific person, with a date, in the moment, instead of hoping a volunteer remembers by morning. The request stops being a hopeful broadcast and becomes an owned commitment.

That’s the real shift. Most “we forgot to do X” isn’t a discipline problem, it’s a translation problem: the work was stated in one place and needed in another, and nobody made the jump. We’re rolling these out so the place your team already talks becomes a place work gets captured, not just discussed. The thread stays a thread. The task becomes a task.

Same channel, same 11am ask. This time Nadia hits the shortcut, sets it to herself, due Thursday morning, and goes back to her bug. The message scrolls away exactly like before, but the work doesn’t go with it. Thursday morning the deploy is sitting at the top of her list, with a link straight back to who asked and why.

Chat is great at starting work and terrible at holding it. The fix isn’t to talk less. It’s to let the talk become tasks on the way past.

A surprising amount of team work is the same shape every time. Onboarding a client, shipping a release, running a campaign. And yet teams rebuild it from a blank page on every go, paying the setup cost again and again, and quietly dropping a step or two whenever they’re busy, which is always. The blank page isn’t a fresh start. It’s a tax you pay for consistency you don’t get.

Build it once, reuse it forever

Turn a repeatable project into a template: the task list, the structure, who usually owns what, and how the deadlines fall. Next time, instantiate it and you’re set up in seconds instead of an afternoon, with nothing forgotten because the template doesn’t forget.

• Default assignees, so work lands on the right person automatically.
• Flexible deadline rules, counted from a start date or pinned to a fixed target.
• One click turns a template into a live, fully populated project.

The deadline rules are the part that saves the most quiet pain. Set “first draft due five days after kickoff” once, and every new project gets dates that make sense for its own timeline, not a copy of last project’s calendar that you have to fix by hand.

It pays off most when the team grows. A new hire running their first client onboarding doesn’t need to absorb fifteen tasks of tribal knowledge or shadow someone for a month. They click the template and they’re running the same playbook as your most experienced producer, on day one. The template is how “the way we do things” stops living only in Elena’s head.

Now Elena’s onboarding is a template. New client, one click, and there’s the whole project: fifteen tasks, the right owners, dates counted from today’s kickoff. The access requests are right there at the top where they belong, because the rushed version of Elena and the careful version of Elena now produce exactly the same project.

The reward isn’t just speed. It’s that every project starts complete, and the step someone always forgets is already on the list.

There’s no single right way to look at your work, but most tools pick one for you and make you live with it. So you either fight a list when you need a map, or fight a board when you just want to put your head down. Either way you’re spending attention on the view instead of the work, which is exactly backwards.

One set of tasks, two ways to see it

Switch to the board and your tasks line up in columns by status. Drag a card from one column to the next and the status updates, no opening the task, no dropdown. Reorder within a column to set what’s next. Switch back to the list when you want linear, and it’s the same tasks, because it’s the same data underneath.

• Drag across columns to change status, drag within one to reprioritize.
• The list view has the same drag to reorder, for when you’d rather stay linear.
• Nothing to sync and nothing to set up, the two views are the same work seen differently.

That last point is the quiet bit that matters. These aren’t two separate tools you have to keep in agreement. Move a card on the board and the list already knows. There’s no migrating, no “which one is the real one,” no version of your work that’s secretly out of date.

For a team, the board earns a second job: it’s the standup. Instead of everyone narrating what they’re doing, you look at the columns together and the state of the work is just there, visible, current, no status meeting required to assemble it. The list is for the individual head down. The board is for the team’s shared glance.

So Ava stops choosing once and for all. Monday she’s in the list, head down, working a column. Wednesday she flips to the board, sees the whole project at a glance, drags two cards into review, and flips back. The view bends to the day instead of the day bending to the view.

The tool shouldn’t make you think the way it thinks. Same tasks, your call on how to see them.

Multitasking feels productive and almost never is. Every time you switch tasks you pay a tax to reload the new one into your head, and a day of switching is a day spent mostly paying that tax. Worse is what a full view does to your attention: when everything is visible at once, everything competes at once, and the part of your brain that should be doing the work is busy refereeing the list instead. Seeing all of it is the thing stopping you from doing any of it.

The case for one thing at a time

The antidote is almost rude in its simplicity: do the next thing, and only the next thing. Not the best possible task chosen after weighing all twenty three. Just one good next action, picked quickly, with the other twenty two deliberately out of sight while you do it. The point of a plan was never to stare at the whole plan. It was to free you to ignore most of it and trust the one piece in front of you.

• Pick a single next action, small enough to actually start.
• Put the rest out of view, it’ll still be there, it doesn’t need watching.
• Give it a real block of time, and let that block be the only thing that exists for a while.

This is why focus blocks and a calendar matter more than another clever way to sort your tasks. A block of protected time is permission to narrow your attention to one thing without guilt, because you’ve already decided everything else waits until later, and later has a real slot. The schedule is what makes single tasking safe: you can ignore the other twenty two because you know exactly when each will get its turn.

So Maria stops trying to hold twenty three things and picks one. She blocks an hour, puts the rest away, and works the single task in front of her until it’s done. Then the next one. The board didn’t get shorter by magic, it got shorter because she stopped staring at all of it at once and started moving through it, one honest piece at a time.

You can’t do twenty three things at once. You can only ever do the next one. A good system isn’t the one that shows you everything, it’s the one that lets you safely ignore almost all of it.

The best moment to capture a task is the instant it occurs to you, and that moment is brutally short. Every bit of friction between the thought and the saved task is a chance for the thought to evaporate, and complicated capture doesn’t just slow you down, it teaches you not to bother. So the ideas you don’t write down become the work you’re surprised by later.

A little syntax goes a long way

Type the task in plain words and go. That’s the whole baseline, no syntax to learn before you can start. When you want more structure, a couple of characters do the work no menu should make you hunt for.

• Use > to add a task that depends on the one before it, capturing a whole chain in a single line.
• Use * to get a heads up when a task is completed, so you can follow work without babysitting it.
• Everything else stays plain words, nothing to memorize.

So Tom’s four second thought, “send contract > brief designer > start designs,” goes in as one line and comes out as three linked tasks in the right order. The dependency means the designer brief won’t nag him until the contract is actually sent. The chain captures itself as fast as he can think it.

The heads up character earns its keep when you’ve handed something off. Mark a task you’re waiting on, and you’ll know the moment it’s done, without pinging the person every afternoon to ask. You get to stop holding the thread in your head, which is the whole point: the tool remembers so you don’t have to.

None of it is mandatory. You can live happily on plain words forever and never touch a single symbol. But once the syntax is in your fingers, a whole sequence of work travels from your head to the app in the time it used to take to write one task. The thought still arrives mid sentence. The difference is what happens next: a single line, a couple of characters, and it’s safe, structured, and out of his head before he’s lost his place.

Capture should keep up with your typing, not interrupt it. The fastest task manager is the one that’s already done before the thought has finished forming.

Coordinating a team is mostly a question of timing, and without a shared answer to “when is everyone actually free,” you’re left with two bad options: interrogate people one by one, or book a slot and hope. The first is slow and annoying. The second is how someone’s only protected focus block of the week gets a meeting dropped on it, and how you become the reason their Thursday fell apart.

Everyone’s availability, in one overlay

The team calendar shows your teammates’ busy and free time together, so you can find the slot that works for everyone without sending a single “does this time suit you?” message. You see the gaps directly, and you book into one that’s genuinely open for all four.

• See busy and free across the team: the timing is shared, the details stay private.
• Everyone controls how much of their calendar they expose.
• Plan and book around real availability, not assumptions.

The privacy line is deliberate. You don’t need to see that someone has a doctor’s appointment to know they’re busy at 3pm. So the overlay shows the shape of the day, busy here, free there, and keeps the contents to themselves. Enough to plan around, never enough to snoop.

It quietly changes the culture too. When everyone can see availability, “let me check with the team” stops being a day long relay and the constant low hum of scheduling pings fades out. People interrupt each other less, not because they care less, but because they don’t have to ask a question the calendar already answers. And because focus blocks show up as busy, the team’s protected time defends itself: you can’t book over the deep work you can’t see, but here you can see it, so you don’t.

Now Ben opens the team week, sees the one ninety minute window where all four are genuinely free, and books it. No thread, no four way negotiation, no accidentally bulldozing someone’s deep work. The meeting that used to take a morning to schedule takes about ten seconds, and nobody’s Thursday gets ambushed.

It’s the difference between coordinating a team and constantly interrupting one. The week gets planned. The pings stop.

That’s the trap with gamifying a task manager: do it carelessly and you don’t measure productivity, you manufacture theater. People optimize for whatever you count, so if you count checkboxes, you get more checkboxes and not one more hour of real work. Worse, you teach a team to perform busyness, which is the precise opposite of what you wanted. The metric becomes the goal, and the goal quietly dies.

Points for focus, not for noise

Arena, the light competitive layer we’re building, scores the one thing that’s genuinely hard to fake and worth protecting: time spent in focus blocks. Real, head down work. Not the number of tasks ticked, not the volume of activity, just the hours you put into doing the work that matters.

• Earn points from focused time, the thing worth defending.
• A team leaderboard that nudges good habits gently, never a guilt trip.
• Entirely opt in: if a scoreboard isn’t your thing, ignore it and nothing changes.

Tying the points to focus time is the whole design decision. You can’t game it by chopping up tasks, because tasks aren’t what’s counted. The only way to climb is to actually protect and spend focused hours, which means the leaderboard and your real output finally point in the same direction.

So the version Ravi might actually trust looks different. Nobody’s inflating their task count, because it doesn’t matter. The thing that earns a little friendly status is the thing he wanted his team doing anyway: defending their deep work and using it. A small spark of momentum, pointed at the right target.

A scoreboard teaches a team what you value. Point it at focus, and you get more focus. Point it at activity, and you get a very busy team that ships nothing.

It’s on the way, opt in from the start, and we’re shaping it with the teams who want it. The aim is a reason to protect your deep work that happens to be a little fun, not a surveillance dashboard. Those are very different products, and we know which one we’re building.

More and more planning starts in a conversation now. You think out loud with an assistant, it helps you structure the work, and you end up with a clean plan in the wrong place. The bridge from that plan to your actual backlog is forty minutes of mindless copying, and it’s exactly the kind of dull, error prone data entry that the assistant could obviously do, if only it could reach your tools.

Skip the retyping

UnaTask speaks MCP, the open standard for connecting AI assistants to real tools. Connect an assistant like Claude, or your code editor, with a personal token, and it can create projects and tasks in your workspace directly. The plan it just helped you write, it can also file.

• Turn a planning chat into a populated backlog in one step.
• Create tasks in bulk, a whole project structure at once instead of one at a time.
• You stay in control: it’s your token, your workspace, your rules.

Because it’s a personal token scoped to your workspace, nothing happens that you didn’t authorize, and you can revoke access whenever you like. The assistant doesn’t get the keys to everything. It gets a specific, revocable door into the one workspace you pointed it at.

The bulk part matters more than it looks. Filing one task by hand is fine. Filing a forty task project breakdown by hand is where good plans go to die, because nobody wants to do it, so it gets done badly or not at all. Letting the assistant create the whole structure at once means ambitious plans actually make it into the system intact, at the exact moment your motivation is highest.

So Cleo’s launch plan never gets retyped. She finishes the conversation, the assistant writes the projects and tasks straight into UnaTask, and she switches tabs to find the whole backlog already there: phases, tasks, owners, ready to work. The forty minute copying chore is just gone, and the plan goes from idea to backlog without her touching a single form.

Think out loud with an assistant, then let it do the data entry. The plan should land in your backlog, not in a transcript you have to retype.