Tasks that open themselves

Some teams manage tasks; others type them in. The difference is not the tool but the answer to one question: who puts the task inside. Here most tasks are never typed at all. They arrive from the places where they were already born.

Where a task comes from

A task is born several ways, and all of them run at once. The customer's ticket system brings them in by sync: the ticket number, the text as written, and the status in the very word the vendor uses. An incoming email becomes a task. A WhatsApp message becomes a task. An error that repeated in monitoring becomes a task and stays tied to the error group it came from. And whoever wants to can open one by hand and pick where the request came from: phone, mail, WhatsApp or other.

The ratio differs per project; what does not differ is that none of them was typed twice.

What the card holds

The original text is kept as it arrived and is never rewritten. Beside it sit two numbers, ours and the vendor's, and both are shown: in conversation with the customer you use theirs.

Inside there is our working status, and alongside it the vendor's status name is stored in the vendor's own words, whether that is Hebrew or "Code Review".

A card has a department, a priority, a due date and an hours estimate. The department may stay empty until triage: at the moment a task appears, usually nobody knows it yet.

Hours, and a rate locked at the moment of writing

Hours are written against the task, and every entry stores the rate it was written at. This is not a detail: changing a rate tomorrow does not rewrite work already done.

• Every line of hours also knows who entered it and from which organization, which matters exactly when a project has more than one contractor;
• there are internal hours as well, visible only to the organization's owner.

They exist so the truth can be recorded even where the truth is not sent to the customer.

A monthly cap that does not stop the work

A task can be given a monthly cap in money. The number sits on the task and does not change, the count runs by month, and on the first of the month it starts from zero.

Two decisions worth knowing in advance. Empty is not zero: empty means "no cap", zero means "nothing may be spent". And reaching the cap does not block time entry: both sides see the highlight and whoever logs an hour gets a warning, but the entry goes through.

A block would stop the work silently, at the precise moment when people, not a database column, should be deciding.

What the customer sees and what they do not

The card holds two different texts, not one: what was written inward to the team, and what was answered to the customer. These are different things, so they are two fields.

And one rule that surprises at first and turns out right on reflection: a task with no assigned provider is visible to the customer only. A task born from a mail or an error and not yet handed to anyone is, for now, the customer's business alone.

What leaves the task

From a task you can open an entry in the journal, and it stays tied to it. A resolution can become a knowledge base article, so the next identical answer is found without a person. And the hours recorded on it reach the customer's monthly report without a separate step.

Who may open a task

Opening a task is a right of its own, not a consequence of a job title. It is checked in one place, at creation, so every route a task can appear by passes the same check.

What we have not verified in production

Automatic technical analysis of a task exists in the system, but on the live project it has been run only a handful of times. We would rather write it that way than promise it.