Skip to content
Workflow automation

Automate the paperwork, keep the judgement

Most of what a supervisor does in a day is transcription: re-raising the same weekly job, telling someone it exists, writing the evening summary, checking a message was seen. All four can be automated. Deciding who should do the work, and whether it is actually finished, should not be.

Included on every plan term — there is no separate automation tier.

Sound familiar?

The problems this page is about

If none of these describe your week, a different page on this site probably does.

How it goes today

  • The process only runs when a specific person runs it

    One supervisor holds the cadence in their head. Their leave is the reason the monthly reconciliation happened on the 12th.

  • Automation projects that never finish

    A rule engine promises everything, needs someone to design and maintain the rules, and ends up as three half-built flows nobody trusts.

  • Notifications that need a second notification

    Work is assigned in one system and announced in another, so the two disagree and people learn to trust neither.

  • Reports are written, not generated

    The daily summary is a person retyping what the records already contain — and it stops the week they are away.

With TaskIt

  • Scheduled generation of real tasks

    Daily, weekly, monthly, yearly and custom cadences in a chosen time zone, each producing an ordinary task with the normal lifecycle, assignment, notification and audit rules.

  • Event notifications that need no second step

    Task creation, handover and completion each trigger in-app and optional WhatsApp messages, switchable per event and targetable at the person, a group or both. Creating the task is what tells people about it.

  • Reporting that arrives on its own

    Daily, weekly and monthly WhatsApp reports at a set time in your workspace’s time zone, with the statistics window following the cadence, plus live preview and a test send before anything goes out.

  • Delivery you do not have to supervise

    Every outbound message goes through a persistent queue with retries, exponential backoff, de-duplication and crash recovery — so a restart mid-broadcast resumes rather than loses.

  • Idempotence rather than good luck

    Each recurring occurrence is claimed under a unique constraint before a task is created, so two overlapping scheduler ticks cannot produce the same task twice.

Worked example

Automating a month-end close

Six repeating jobs and one report, set up in an afternoon.

  1. 1

    Six schedules

    Bank reconciliation, supplier statements, payroll inputs, GST working, stock valuation and the management pack — each with its own cadence and day of month.

  2. 2

    One department

    All six raised for Accounts rather than for one person, so a holiday does not stall the close.

  3. 3

    Notification on creation

    The Accounts group is told as each job appears. Nobody sends a second message.

  4. 4

    A daily report at 18:00

    What was assigned today, what is in progress, what completed and anything blocked — delivered whether or not the supervisor is in.

  5. 5

    Evidence afterwards

    Execution history shows each occurrence that ran; the Recurring Execution Success Rate report shows which routines are being completed rather than merely created.

The result

The close now happens on the same days every month, and the only manual step left is the judgement about what the numbers mean.

What you end up with

The result

No percentages, because nothing here has measured yours — these are the changes the mechanism produces.

The routine no longer depends on a person

Cadence, template and assignment live in the schedule. Leave and turnover stop being reasons a process slipped.

Nothing to design and nothing to maintain

There is no flow diagram to keep in sync with reality, because the automation is a fixed set of capabilities rather than a canvas.

Failure is visible

Execution history records every attempted run and delivery history records every message, including the ones that failed and why.

A clear boundary you can plan around

Knowing what is not automated is as useful as knowing what is — and it prevents a trial spent looking for a rule builder that does not exist.

What is automated, and what deliberately is not
AutomatedNot automated
Creating recurring tasks on a cadenceDeciding who should do a piece of work
Notifying on creation, handover and completionAuto-assignment by workload or skill
Daily, weekly and monthly report deliveryConditional routing between custom stages
Retrying failed message deliveryDeciding whether work is genuinely finished
Inheriting a department from the assigneeBuilding your own if-this-then-that rules
FAQ

Frequently asked questions

No, and this is worth knowing before a trial rather than during one. TaskIt ships a fixed set of automation — recurring task generation, event notifications, scheduled reports, a retrying delivery queue and department inheritance. There is no rule engine, no flow canvas and no conditional routing between custom stages.

Not by workload or skill. The intended answer to "I do not know who should do this" is a department queue: the task is raised unowned for the whole team, everyone eligible is notified, and the first person free claims it.

The work that repeats on a fixed cadence and currently depends on somebody remembering it — opening and closing routines, weekly reconciliations, monthly filings. Those give the clearest benefit and are the easiest to verify from the execution history.

It is retried automatically, up to five attempts with backoff, because every message goes through a persistent queue rather than a direct call. Delivery history records the status, the retry count and the error.

Keep reading

Where to go next

The capabilities behind this page, and the neighbouring situations they also cover.

Automate one afternoon’s worth of admin

Turn your five most repeated jobs into schedules and switch on the daily report. That is usually the whole first sitting.