Running jobs on a schedule

TL;DR:

• Pick a site, say what you want, and DuckyHelper can keep doing it on a schedule or when something changes there.

• It uses what it learned about the site, and is still built to ask first before it sends or pays.

• Always-on automations are early access.

A lot of useful work is not a one-off. It is the same small job, done again whenever something comes up. We built always-on automations for that kind of work. They are in early access.

A job that repeats

The idea is simple. You pick a site, say what you want, and DuckyHelper keeps doing it. It can run on a schedule, such as every morning, or whenever something changes on that site: a new message arrives, a price drops, a new order comes in, a form is submitted. (This is early access.)

In early access, you describe an automation in the same way you would describe a job to a person. For example: the site is your recruiting inbox, the task is to reply to new messages with your template, and anything unusual comes to you first. You say it once, and from then on it runs by itself.

Why it can be cheap and fast

Repeating a job is where the idea in how DuckyHelper learns a website once and reuses it pays off. DuckyHelper uses what it learned about the site, so each run is quick and light and does not start from scratch. A schedule would be wasteful if every run had to click through the page again. (This is early access.)

Good jobs to schedule

In early access, the best candidates are jobs that are regular, well defined and easy to undo. A few kinds that fit:

• Collecting something on a timetable, such as pulling a weekly report into a sheet.

• Keeping watch on a page and letting you know when it changes.

• Sorting or tagging new items as they arrive.

• Drafting a reply to a common message and holding it for your OK.

What these have in common is that a mistake is small and visible. If the sort is a little off, you notice and fix it.

What still waits for you

Running by itself does not mean running without limits, even in early access. DuckyHelper is still built to ask first before it sends a message or pays for anything. An automation that is set to answer messages prepares the reply and then asks, the same as any other job: you see it and can send it, edit it or deny it.

It's also built not to type your passwords or card numbers. If a site signs you out, signing back in is yours to do.

Seeing what ran

Each run leaves a record, so you can see what happened and when. A history of runs, with a check by each one that finished, shows at a glance that things are working. The steps of a run are written in the same plain steps as any other job.

What we think should not be automated

Anything where being wrong is costly and hard to take back should have a person in the loop. That is why sends and payments stop for you. A good test is to ask what the worst outcome of one wrong run would be, and automate only when you could live with it.

An example

Say you track the price of a part you plan to buy. You pick the shop's page, say that you want to know when the price drops, and DuckyHelper checks it for you. When the price falls, you get a note. It does not buy the part, because paying is one of the things it's built to ask you about first.

That shape recurs in most good automations. DuckyHelper does the watching and the preparing, and you make the decision at the moment it matters.

A job you have just done once is a natural candidate. When a task looks like something you would want again, DuckyHelper can offer to make it automatic, showing when it would run and what it would do, and you choose whether to turn it on. Nothing becomes an automation without your say.

What this means for you

Start with a small, low-risk job, watch a few runs, and widen it as you trust it. As this is early access, expect it to keep changing, and tell us what you would like it to do at support@duckyhelper.com.