Train Viktor's brain

Onboard Viktor the way you would onboard a real hire. Start with who the company is, then who does what, then the jobs you want him to own.

1. Feed him the company first.

   Like any new employee, Viktor starts with overall company info: what the company sells, who the customers are, what words you use and never use. Say "remember this" and he stores it permanently. You should never have to explain your company twice.

2. Then the people: who does what.

   Who is who, who owns which area, who approves what. This is how Viktor knows who to ask, who to tag, and whose preferences apply to which work.

3. Now map the jobs you want delegated.

   List the outcomes you want off your plate across marketing, sales, operations, finance, and personal work. Prioritize the first 3 to 5 jobs by value and repeatability, and write a short role brief for each: mission, responsibilities, what good looks like, and approval rules. Keep the roles separate so a correction to the finance analyst does not accidentally change the content writer.

4. Connect Viktor to your systems and tools.

   CRM, email, calendar, analytics, billing. An AI employee without integrations is a consultant without system access: smart but guessing. Connect the 3 to 5 tools your team argues about data from, first.

5. Correct him like you would correct a junior hire.

   When he gets something wrong, do not just fix it yourself. Tell him what was wrong and what the rule is. He writes it into his skills and the mistake does not repeat. Every correction is a permanent training investment.

6. Ask him what he is missing.

   After a week, ask: "based on everything you have seen, what context do you not have that would make you better at this job?" He will tell you. Fill the gaps.

Organising Viktor: one person, many hats

Viktor is one person, not a fleet of bots. He wears a different hat in each channel of Slack and Microsoft Teams: your channel structure is how you hand him each hat.

1. One channel per workstream, not one channel for everything.

   #marketing-viktor, #sales-ops, #finance-reporting. Same Viktor everywhere, but each channel gets its own instructions, so he shows up wearing the right hat: different tone, different rules, different default actions.

2. Give every working channel a 5 line instruction set.

   Who owns the channel, what Viktor should do there by default, what he must never do without sign off. Ask Viktor to set channel instructions and he does it himself.

3. DMs for personal work, channels for team work.

   Your inbox triage, your day planning, your drafts live in a DM. Anything the team should see lives in a channel. Viktor keeps DM content private by default.

4. Add Viktor to the channels where decisions happen.

   Even if you do not @ him yet. He reads context. When you finally ask "prep me for the Acme renewal", he already knows the whole history.

5. Set up a weekly 1 on 1.

   A recurring prompt: what did you ship this week, what did you notice, what do you recommend. This turns Viktor from reactive to proactive and it is where the compounding shows.

Mastering crons

Crons are recurring jobs Viktor runs on a schedule: daily reports, inbox sweeps, pipeline checks, competitor monitoring. Done right they are the highest ROI feature in the product. Done wrong they are a credit furnace that posts noise nobody reads.

1. Create your first cron in one plain sentence.

   Schedule, task, destination. For example: "Every weekday at 8am, check the support inbox and post anything that needs a reply to #ops." Or: "Every Monday morning, summarize last week's sales pipeline changes in #sales." That one sentence is the whole setup, Viktor builds it from there.

2. Run it manually 2 or 3 times before you schedule it.

   Before it goes on the calendar, ask Viktor to do that exact task live, right now. Correct the output until it is right, THEN say "now run this every weekday at 8am". Never schedule a task you have not seen succeed.

3. Give every cron a "stay silent" condition.

   The best crons only speak when something changed or crossed a threshold. "Post only if a deal moved stages" beats "post the pipeline every day" after week two, because people stop reading unchanged reports.

4. One cron, one job.

   A cron that checks email AND updates the CRM AND posts a summary will fail in ways that are hard to debug. Three small crons beat one mega cron.

5. Tell the cron when it gets something wrong.

   Corrections to a cron persist the same way skills do. "The revenue number was wrong because you counted refunds, exclude them" fixes every future run.

6. Review your cron list monthly.

   Ask Viktor: "list all my active crons, when they last ran, and what each costs per month". Kill the ones nobody reads. Most workspaces have 1 or 2 zombie crons burning credits for a channel nobody opens.

Planning your work

The most expensive Viktor mistake is letting him run a big fuzzy task with no checkpoint. The fix is one habit: for anything non trivial, ask for the plan before the work. This guide has two parts: five planning habits, then a prompt structure for high stakes work.

Part 1: Five planning habits

These are not steps you do in order. They are five separate habits, pick the ones that fit the task in front of you.

1. Say "make a plan first, do not execute yet".

   Viktor comes back with steps, what he will touch, and what he needs from you. You approve, adjust, or kill it in 30 seconds. This catches wrong assumptions before they cost hours and credits.

2. Use it for anything that touches the outside world.

   Emails to customers, CRM writes, published pages, payments. The pattern is: draft, review, send on approval. Viktor already asks for approval on sensitive actions, but saying "always show me before sending" makes it a standing rule.

3. For big projects, ask for a todo list he maintains.

   "Break this into steps, keep a running checklist, update me as you finish each one." You get visibility, he stays on track, and you can redirect mid flight instead of at the end.

4. Ask for the cheap version first.

   "Give me a one paragraph answer before you do the full analysis." Half the time the paragraph is enough and you saved 90% of the cost.

5. When the plan is approved, get out of the way.

   The point of planning up front is that execution then runs without you. Plan, approve, receive finished work.

You: "We are switching our welcome emails to the new pricing.
Make a plan first, do not execute yet."

Viktor: "Plan: 1) pull the 6 current welcome emails,
2) update pricing and links, 3) show you all 6 drafts
for approval, 4) publish after your OK.
I need: the new pricing page URL. Anything to add?"

You: "Approved. Also keep the founder PS line unchanged."

Part 2: A prompt structure for high stakes work

Separate from the habits above. When the work is consequential, an important client email, a report leadership will act on, build the request itself in four layers. Use only the layers that correct the failure mode you expect.

1. Outcome: what must be true at the end?

   Define the finish line before the method. Example: "The customer should receive a correct renewal recommendation with every number tied to a source."

2. Boundary: what is inside and outside scope?

   Prevent a small task from becoming an unnecessary refactor. Name what Viktor may change, what he must leave alone, and when he should stop to ask.

3. Evidence: how will the result be verified?

   Specify the source of truth and the proof required. Ask Viktor to inspect or run what the user will actually experience, not merely say that it should work.

4. Handoff: what should the final answer contain?

   Constrain the report to the outcome, relevant evidence, and any decision still required. Complex work does not need a complex handoff.

Follow this protocol.

1. PLAN: Define the perfect end state and the steps required.
2. EXECUTE: Carry out the plan completely without shortcuts.
3. VERIFY: Check every part against the original request and fix mismatches.
4. REPORT: State the outcome, evidence, and any decision required in one to three sentences.

Do not skip or compress a stage.

Credits without waste

Three parts: how credits work, how not to waste them, how to train a team on them. This is the number one question specialists get from clients, so it doubles as your cheat sheet.

Part 1: How credits actually work

1. Credits are one pool per workspace, not per seat.

   Adding teammates does not cost more credits. The right move is always to get the whole team in: usage is what you manage, not seats.

2. Cost follows thinking and doing.

   A quick answer is cheap. A deep research report with 50 sources is not. A cron that runs daily costs its price times 30 every month.

3. Model choice is the biggest single lever.

   Heavier models cost roughly 2 to 3x more per unit of work. Most routine work (summaries, triage, formatting, standard reports) is indistinguishable on a lighter model. Save the heavy model for judgment work: strategy, complex analysis, high stakes writing.

4. If you keep buying top ups, your plan is wrong.

   Top ups are for spikes. Three top ups in a month means you should move up a tier: it is cheaper and you stop thinking about it.

Part 2: The five waste patterns

1. Zombie crons.

   Scheduled jobs posting into channels nobody reads anymore. Fix: monthly cron review, kill anything without a reader. Usually the single biggest recovery.

2. Blowout threads.

   One giant vague request ("analyze everything and tell me what to do") that runs long and wide. Viktor takes the vague ask seriously, pulls every source he can find, and produces a 20 page answer to a question nobody quite asked. You spot them by feel: the thread runs much longer than expected and the output is broad instead of useful.

   Three fixes, in order of impact:

   1. Scope the ask before sending: name the question, the sources that matter, and the output you want. "Why did trial signups drop last week? Check ads and the signup funnel, 5 bullets max" instead of "figure out what is wrong with growth".

   2. Ask for the cheap version first: "one paragraph before the full analysis". Half the time the paragraph is enough.

   3. For anything genuinely big, use the plan first habit from Guide 04, so the shape of the work is agreed before the credits are spent.

   And if a thread is already blowing out, say stop. Redirect mid flight instead of letting it finish and asking again.

3. Retry loops.

   Asking again slightly differently because the first output missed. Three retries cost three runs. Fix: correct instead of retry. "Same output but exclude refunds and shorten to 5 bullets" is one cheap run and it teaches him permanently.

4. Heavy models on routine jobs.

   A daily summary cron running on the most expensive model. Fix: audit which crons run on which model, downgrade the routine ones. Often 1 or 2 crons account for most of the heavy model burn.

5. Re-teaching context.

   Explaining your company, your format, your rules in every thread. Fix: say "remember this as a rule" once. Context that lives in skills is free forever; context re-explained in every message is paid every time.

Part 3: Training the team (norms beat limits)

1. "Correct, don't retry."

   Make it a team phrase. It is the difference between paying once and paying three times for the same output, and only one of them makes Viktor better.

2. Delegate outcomes, not keystrokes.

   "Get me a meeting with Acme's CFO next week" beats 15 separate micro asks. Bigger, well scoped delegations are more credit efficient than chat style usage.

3. Every recurring output needs a named reader.

   Before anyone schedules a cron: who reads this, and what do they do with it? No answer, no cron.

4. Make cost visible, not policed.

   A monthly "ask Viktor where our credits went" review in a team channel. When people see that one zombie cron cost more than all their DMs combined, behavior fixes itself.

Skills: teach Viktor once, he remembers forever

A skill is something Viktor remembers how to do: your report format, your writing voice, your process for a task. You create skills by talking to Viktor in Slack and Microsoft Teams. No tools, no files, nothing outside Viktor.

1. Know what a skill is.

   A skill is Viktor's long term memory of how your company does something. Once he has it, he uses it every time without being reminded. You never install anything, you teach him the way you would teach a new hire.

2. Create skills by asking, in plain English.

   Do the task with Viktor once. Correct the output until it is right. Then say "save this as a skill so you do it this way every time." Viktor writes and stores the skill himself.

3. Correct him and it sticks.

   When something is wrong, do not redo it yourself and do not just ask again. Tell him the rule: "the revenue number was wrong because you counted refunds, always exclude them." He updates the skill and the mistake does not repeat.

4. Ask Viktor what he knows.

   Say "what skills do you have?" or "how do you currently do our weekly report?" He will tell you. Review this with the team once a month, the same way you would review any employee's responsibilities.

5. Test before you rely on it.

   A few days later, ask him to do the task again with no extra instructions. If the output is right without re-explaining anything, the skill works. If not, correct it once more.

Five starter skills: copy, fill in, send

Each of these is a fill-in-the-blank message. Fill in the brackets, paste it into a Viktor channel or DM, and end with 'save this as a skill.' Viktor builds the skill from it. Everything happens inside Viktor.

1. Company context

Save this as a skill.
Company: [name]
What we sell: [products or services]
Ideal customers: [segments and buyers]
Positioning: [why customers choose us]
Approved and banned terms: [list]
Authoritative sources: [docs and systems]
Ask for missing context before building the skill.

2. One role in the job map

Save this as a skill.
Role: [role name]
Mission: [outcome]
Responsibilities: [3 to 7]
Success metrics: [KPIs]
Sources and tools: [systems]
Approval rules: [what needs sign off]
Escalate when: [exceptions]
Keep this role separate from Viktor's other jobs.

3. Writing voice

Save this as a skill.
Person or brand: [name]
Audience: [reader]
Voice: [traits]
Formatting rules: [rules]
Use and avoid: [terms]
Approved samples: [examples]
Test against one new draft before relying on it.

4. Recurring workflow

Save this as a skill.
Workflow: [name]
Trigger and outcome: [start and definition of done]
Inputs and source of truth: [data]
Proven steps and decisions: [method]
Approval checkpoint: [owner]
Output and destination: [format]
Failure handling: [when to stop]
Test manually before scheduling.

5. Standing correction

Remember this correction permanently.
What was wrong: [issue]
Correct rule: [expected behavior]
Scope and exception: [boundaries]
Correct example: [example]
Update how you do this going forward and tell me what changed.

Where instructions live: the 3 layers

Everything you teach Viktor lives in one of 3 layers: skills, channel instructions, and crons. Most implementation problems are good instructions stored in the wrong layer.

1. The how goes in a skill.

   How the report is built, what sources count, what good looks like. Taught once, used everywhere.

2. The room rules go in channel instructions.

   Who to tag, what tone, what he can do here without asking.

3. The when goes in the cron.

   Just the schedule and destination. The cron points at the skill, it does not repeat it.

4. Fix problems in the right layer.

   Wrong numbers: fix the skill. Wrong behavior in a channel: fix the channel instructions. Wrong timing or noise: fix the cron.