Your first day and first week with TaskTreker
A step-by-step plan for the first seven days: what to set up on day one, what to leave alone for now, and how to tell that the assistant is working.
- Who it is for
- Product managers who have just registered a company in TaskTreker and are deciding which channel to connect first.
- What you get
- By the end of the week you have a confirmed context, a working capture loop on at least one real channel, a cleared confirmation queue and a weekly ritual you can repeat.
Step by step
1. Register the company and stop at the connection screen
Registration is self-service: e-mail and password, one company per access. The free plan is available now; payment is not wired up yet, so nothing is charged at this stage and no card is required. After registration you land on the connection screen: three cards for calendar, documents and meetings, and nothing else. That is deliberate. The assistant has no access to anything until you say which channel it may read and what it may do with the material. Do not begin by configuring prompts, rituals or evaluation sets — a channel is the unit that produces material, and without one the rest of the product has nothing to work with. Expected result: you are signed in, the connection screen is open, and you know which three channels the first wave covers.
2. Read the rights before you grant them
Every channel carries explicit rights, shown on its card. Read means the assistant may take material from this channel and extract candidates from it. Send to the model means the extracted text leaves your infrastructure and is processed by the model provider. Process locally means indexing and redaction happen on your side and the raw material is not uploaded. Under each card the interface lists the scopes that are requested and the scopes that are denied. Read that list before connecting, not afterwards: it is the difference between "the assistant sees my calendar" and "the assistant sees every calendar entry and everything attached to it". If a scope looks broader than you need, deny it explicitly — a denied scope is recorded as well. Expected result: for each channel you can say out loud what it reads, what leaves your infrastructure, and what stays on your side.
3. Enable the demo channels and look at the loop
On the connection screen there is a block for trying the product on demo data first. It creates demo channels with synthetic meetings, documents and calendar entries, without a single piece of real material. In about five minutes the confirmation queue fills up, the missed list shows commitments that never became tasks, and the digest is delivered — it has no screen of its own yet, so you read it through the API. Use it to learn the mechanics before you point the product at real documents: what a candidate looks like, what the source link gives you, what happens when you reject an item. Demo channels and real channels behave the same way, so nothing you learn here is wasted. Expected result: a populated queue you have worked through at least once, and a clear sense of which extractions you would have kept and which you would have rejected.
4. Connect your first real channels in a fixed order
Connect the calendar first: invitations, participants and time slots, with the lowest sensitivity of the three. Connect documents second: requirements, specs and notes, where facts and assumptions are extracted with a link to the fragment. Connect meetings last. Meetings carry uploaded recordings and transcripts, and recording plus transcript processing require explicit consent — a checkbox on the card. The consent is revocable at any time, and every grant is written to the consent log with its date, so people whose voices are recorded can see what was granted and withdraw it. If you work with confidential material, connect documents before meetings and keep meetings off until the consent process is agreed with the people involved. Expected result: the connected channels list shows each provider and status, and the consent log shows the grants you made.
5. Clear the confirmation queue
Everything the assistant extracts is a draft. Each candidate carries a kind — task, decision, insight or fact — a confidence value, and a link to the source fragment: a timecode in a recording, a page in a document, a paragraph in a note, plus the quoted text the extraction rests on. You confirm or reject. Rejected candidates do not enter the context; confirmed ones become a task or a context node depending on the kind, and you can override the proposed kind. The assistant proposes, you decide — it never grants itself access to anything. While you are learning the boundaries, reject liberally: a rejection costs one click and keeps the context clean. Expected result: an empty queue, a context that contains only what you approved, and a habit of opening the source fragment before confirming.
6. Read the missed list
The missed list holds what was said but never became a task. Each item keeps the source, the reason why it matters and the deadline. The counter at the top counts only the misses you confirmed: an unconfirmed item is a candidate, not a result. Work through the list at least once during the first week, because that is where commitments falling between the cracks surface — especially the ones from meetings where you were the one taking notes. An empty list is a valid state, not a failure: it means there was no commitment without an owner. Expected result: you either confirmed a real miss, or you accepted that the week was clean.
7. Look at the task list and at the context
Tasks live in one list, and each task keeps the source it came from. Priority is proposed together with a reason, and you can override it: the proposal is there to be argued with, and the reason is what makes the argument possible. The context holds strategy, goals, assumptions, hypotheses and decisions as nodes; each node keeps an owner and the date of its last check, and you can walk from any node back to the source. This is the part that turns a week of meetings into a memory you can consult: the question "why did we decide this" gets an answer with a link to the place where the decision was made. Expected result: a task list you trust enough to work from, and a context that answers at least one "why" question about your own decisions.
8. Set the weekly rhythm and decide when to bring a colleague
The harness is the layer to configure once capture works. It holds nine prompts in English and Russian with versions, evaluation sets and rituals, so you can see how a prompt is evaluated instead of trusting that it is good. The rituals run by day, week and month; for the first month one weekly ritual that reads the missed list and the open tasks is enough. The learning section explains the method on your own data — there is no course behind it, only your material. The check with a novice walks the product through as a first-time user in a sandbox you specify and reports the findings without softening them. Bring a colleague in when the queue has been stable for a week and you trust your own confirmations: a second person confirms that the output is usable by someone who is not you, and a product marketing manager or a seller can look at the delegation part — who takes it, in which format, and why. Expected result: one repeatable weekly ritual and a written decision about when the next person joins.
If it does not work
- The digest and the missed list stay empty.
- Channels are filled manually or with demo data for now: polling connected sources automatically is in progress. Enable the demo channels to see the loop work end to end, and check the status of each connection. Digest delivery runs automatically, but there is no separate screen for it yet — you read the digest and the release history through the API. This is a state of the product, not a misconfiguration on your side.
- The meeting channel cannot be connected.
- Recording and transcript processing require explicit consent, so the connect action stays inactive until you tick the consent checkbox on the card. The consent is revocable at any time from the consent log, where every grant is written with its date. Tell the people whose voices are recorded that the consent exists and where to revoke it — the log is the same record you show them.
- An extracted item looks wrong or out of place.
- Open the source fragment first: every candidate keeps a link to the exact place it came from and the quote it rests on, so you can check it in seconds. If it is wrong, reject it — a rejected candidate does not enter the context and nothing is created from it. If the material contains text that reads like an instruction to the assistant, that text is treated as content, not as a command: the model extracts facts from it and does not follow it, and access decisions are made in code before the model is called. Reject the item, narrow the channel scopes, and turn sending to the model off for that channel if the material is sensitive.
- The queue grows faster than you can read it.
- Do not confirm everything: a queue of confirmed noise pollutes the context and costs you trust in the next confirmation. Narrow the scopes on the channel that produces the noise, turn sending to the model off for it, or switch that channel to local processing so the raw material stays on your side. The queue can be filtered by channel and by kind, so process one channel at a time. Silence is a valid state — an empty queue with a working channel is a normal week.
- The context is still empty although channels are connected.
- Connecting a channel grants rights; it does not upload anything by itself. While automatic polling is in progress, add the first material yourself through the API or enable the demo channels, then work the confirmation queue. Context nodes appear only from confirmed candidates, so an empty context with a full queue means the queue is waiting for you rather than something being broken.