Build a report that writes itself every week

Most people's first instinct with an AI employee is to ask it something. That is a good way to see what it can do and a bad way to get value out of it, because it means the work only happens when you remember to ask.

A scheduled job inverts that. You describe the work once, and it happens whether or not you are thinking about it. This is the shortest path to the thing you actually bought, so it is worth doing before anything else.

Decide what the report should answer

A report nobody reads is usually a report that answers nothing. Before you open Tenfold, write down the one question you want answered every Monday.

"Which deals went quiet this week" is a report. "Sales update" is not. The difference is that the first one has a wrong answer, so it is worth reading to find out.

Open Scheduled Jobs and create the job

In the console sidebar, open Scheduled Jobs and choose New job. Give it a name you will recognise in a list six months from now, then pick the employee that should own it.

The employee matters more than people expect. Each one carries its own memory and its own skills into every run, so the employee that has been working your pipeline all month writes a better pipeline report than one you hired this morning. If you do not have an obvious candidate, this is a reasonable moment to hire one and give it the job permanently.

Write the prompt as a standing instruction

This is the part people get wrong, and it is worth slowing down for.

You are not writing a question. You are writing something that has to make sense on a Monday when you are not thinking about it, against data you have not seen. Three things make the difference: name the source, name the shape of the output, and say what to do when there is nothing to say.

Every Monday, review our pipeline and write the weekly deal review.

For each open deal, check the last logged activity. Flag any deal with
no contact in more than 14 days as at risk, and say what the last thing
that happened was.

Write it as: one paragraph on what changed this week, then the at-risk
list, then anything that closed. Keep it under 400 words.

If nothing has changed since last week, say exactly that and stop.
Do not pad it.

That last line earns its place. Without it you get four hundred words of restated history on a quiet week, you stop reading it by week three, and a job you are paying for quietly becomes noise. An instruction to produce less is often the most valuable line in a recurring prompt.

Set the schedule in your own timezone

Choose Weekly, pick Monday, and set a time.

Set it earlier than feels necessary. The job needs to have finished before you want to read it, not started, and a report that does real research can take a few minutes. 6am for a 9am read is comfortable.

The timezone is stored on the job rather than inferred at run time, so it keeps being 6am for you after the clocks change.

Send it to Slack, then run it once by hand

Turn on notify-on-completion and connect Slack if you have not already. The finished report arrives as a card in the channel you nominate, which matters because a report in an app you have to remember to open is a report you will stop reading.

Then run it once immediately instead of waiting for Monday.

The first run is where you find out your prompt was ambiguous. Maybe it read "gone quiet" as no email rather than no activity of any kind, or it wrote nine hundred words because your definition of "under 400" did not survive contact with an interesting week. Finding that out now costs you five minutes. Finding it out on Monday costs you a week.

What good looks like

By next Monday you should have a report you did not ask for, in a channel you already read, that takes ninety seconds instead of forty minutes.

When the first one is wrong, edit the prompt rather than the schedule. Almost every bad recurring report is a prompt that was written by someone who already had the context, for a reader who does not.

Once this works, the pattern generalises. The same five steps produce a Monday cash summary, a weekly competitor brief, a Friday support-themes digest, or an overnight error triage. The schedule is the product. The topic is just the prompt.

Also covers

Working through the night and handing you the results at 8am. This is not a separate feature to configure. It is what a scheduled job is: it runs on your cron, in your timezone, whether or not anyone is signed in, and the finished work is waiting when you are.

The only decision worth making deliberately is what time. Set the job to finish before you want to read it rather than to start then, and remember that a job doing real research takes minutes rather than seconds.

Keeping a running record of what every employee produced and when. Every run leaves a work log entry and a reviewable deliverable, so the history exists without anyone maintaining it.

That record is worth reading occasionally rather than only when something fails:

Show me every scheduled run from the last month: which job, which employee,
when it ran, how long it took, and whether it produced something.

Flag any job that has produced nothing for two runs in a row.

A job that runs successfully and produces nothing is the failure mode nobody notices, because it does not error. It is usually a prompt whose conditions stopped matching — a filter that no longer catches anything, a report about a thing that ended. Two empty runs is the point to look.