Specialists who have run several client implementations agree on one setup order: start as a Slack admin, set Viktor up, then step down to a regular Slack member of the client’s workspace for the rest of the project.

1. Join as a Slack admin for setup. Ask the client to invite your own login to their Slack workspace and give you admin rights for the setup phase. Admin lets you install Viktor, connect the client’s apps and set permissions without waiting for someone at each step.
2. Set Viktor up. Install Viktor, agree the project channel, set who can use Viktor together with the client, and connect and test the apps (steps 2 to 4 below).
3. Step down to Slack member. Once setup is done, ask the client to change your role to a regular member. You keep full visibility of the channels you work in, and the client keeps control of admin-only settings.

Agree the admin window and the step-down date in writing before you start. Admin is for setup, not for the whole engagement.

A Slack role and a Viktor admin/member role are different things. Agree with the client whether you hold the Viktor admin role during setup or their admin makes the admin-only changes together with you.

If the client cannot grant admin rights for setup, ask them to join the setup sessions and make the admin-only changes with you, or ask the Viktor team to check an alternative.

Check Settings → Permissions for the client’s workspace with the client’s Viktor admin (or yourself, if you hold the Viktor admin role during setup). Then confirm access together in the client’s Slack project channel using the checks below.

• Check Who can use Viktor. If the workspace uses Only allowed people, add the specialist to that list. Otherwise, make sure they are not blocked.
• For a Slack guest, also enable guest access. If access is restricted to specific guests or channels, include the specialist and the project channel.
• Make sure both the specialist and Viktor are in the project channel.

Important: enabling guest access does not bypass the general allowlist. Both checks must pass. If guest access is limited to the project channel, do not assume a Viktor DM will work too.

Test in that channel:

“@Viktor, please confirm you can respond to me here. Don’t change anything.”

Slack guests: if you do not already belong to the client’s Viktor workspace, ask its Viktor admin for a separate Viktor workspace invitation addressed to the email you use in that Slack workspace. Enabling guest chat access does not grant dashboard membership. Confirm the invitation and test sign-in before starting work that needs the dashboard.

For integration setup and other dashboard work, open app.viktor.com ↗ and sign in through Slack using your own account in the client’s Slack workspace.

• If a workspace option is available in your account menu, use it to select the client’s signed-in workspace.
• If it is unavailable, sign out and sign in again through Slack, selecting the client’s workspace.
• Check the workspace name before changing anything.

If the client’s workspace is still missing, ask its admin to check your membership and the email used for the invitation. Channel access alone does not establish dashboard access. Do not create a new workspace as a workaround.

The client should connect their business accounts through Integrations ↗, using the app’s secure connection flow. Do not ask them to send passwords or API keys in chat.

Check each connection separately:

• Is it the correct client account?
• Does its Access setting allow the specialist to use it?
• Who can change its settings or disconnect it?
• Which actions are allowed, blocked or require approval?

Being able to talk to Viktor does not mean you can use every connected app. A project channel is not a substitute for integration access controls.

Review existing workspace-wide connections before granting specialist access, not just new connections for the project. A shared connection may expose more data than the project needs. Use restricted access and a suitably limited client account where supported. If the required restriction is unavailable, have the client operate that connection rather than share broader access.

Agree with the client who authorizes messages, record changes and other live actions. Verify the actual approval settings before testing; do not assume an approval prompt goes to the client. It may go to the specialist who requested the work.

Start with a small read-only request against an agreed test record. Confirm that it returns the correct client data before testing actions that change records or send messages. Keep demos and live client work separate.

A read-only test confirms that the connection works; it does not prove the complete security boundary. Review account scope, access lists and approval settings separately.

Build the client’s skills and scheduled tasks in their workspace, not your own.

Before completing the project:

• Document what was built, how to run it, its schedule, connected accounts and approval settings.
• Have a client owner run the workflow using their own access, not just watch you run it.
• Confirm the client can operate and manage scheduled tasks without depending on your identity or connections.
• If you built a Viktor Space, confirm the client can operate and manage it, and check its access and integration dependencies separately. A client being able to open it does not prove it will keep working after your access is removed.
• Agree on ongoing support or an access-removal date. Before removal, confirm the client can operate and manage the workflow without your identity or connections. At the agreed end date, revoke the relevant Slack, Viktor and connection access, then have the client rerun the workflow. If dependencies cannot be resolved, pause the affected automation and get help rather than leaving unnecessary access indefinitely.

Slack Connect only shows you the shared channel. You miss the rest of the client’s workspace and the context Viktor and the client actually work with, so you cannot see how Viktor behaves elsewhere or catch problems early. Specialists who have tried both recommend joining the client’s workspace directly. Use Slack Connect only if the client’s policy rules out membership entirely.

The client creates a shared channel and adds their Viktor. Its Viktor admin first checks that Use Viktor in Slack Connect channels is enabled in Settings → Permissions, then reviews the channel in Slack Connect channels:

• External participants can trigger Viktor: allows people from the external workspace to request work.
• Viktor can send without approval: separately controls whether Viktor can post without a private approval preview.

The workspace-wide Slack Connect switch and the channel’s external-trigger setting must both permit access. Applicable general user-access rules must also allow the specialist.

Enabling external prompting lets outsiders request work using the client’s available integrations and data. Review integration access first, and keep posting approval enabled during testing.

Slack Connect does not make you a member of the client’s Viktor dashboard. Arrange dashboard access separately if needed.

Arrange setup with the client’s Microsoft 365 admin and confirm Viktor is installed and allowed in the intended location. An invitation or admin consent alone does not install Viktor.

For guest or cross-organization work, contact the Viktor team to verify the intended setup before committing to that access route. Do not treat Teams shared/external conversations as equivalent to Slack Connect, or assume Teams-only users have Viktor web chat.

Hi [Name],

To build this in your Viktor workspace, please invite [my email] to your Slack workspace with admin rights for the setup phase, and add me and your Viktor to [project channel]. Admin lets me install Viktor, connect your apps and set permissions without blocking you at each step. Once setup is done (target: [date]), please change my role to a regular member for the rest of the project.

We’ll check Settings → Permissions together so I’m allowed to use Viktor, both during setup and after the role change.

If your policy does not allow admin or membership, let me know and we’ll set up a guest access or client-operated setup sessions instead.

If dashboard work is needed, we’ll also confirm I can sign in to your Viktor workspace using my own identity. Please connect the required business apps using your own accounts and grant me access only to the connections needed for this project. No passwords need to be shared.

Please also review existing workspace-wide connections so my access does not include unrelated business data.

We’ll agree who authorizes live actions and verify where approval requests go before testing. Before handover, we’ll confirm you can run and manage the workflow independently, agree how my access will end, and test again after the agreed access removal.

Thanks, [Your name]

1. 1
   Walk me through your day — what's the very first thing that happens?Then "and then what?" on repeat.
2. 2
   How long does that step take? How long do you wait?Find what ends the wait. Choose a scheduled check, an event-based workflow or a human step after checking the available tools.
3. 3
   What's supposed to happen and sometimes just doesn't?The gold is in the cracks
4. 4
   What are the rules? If X happens, what do you do?Rule-based work is a candidate. Verify tool access, data permissions, exceptions and the cost of errors before committing.
5. 5
   Which tools does that touch, and whose accounts are they?
6. 6
   Who will work with Viktor day to day?Your champion
7. 7
   Who approves access and outbound actions?

• Record with permission. No recording → their exact words, written up the same day
• Explore relevant departments with permission; expand only where there is a useful workflow and an owner
• "Can it read a blueprint?" Don't guess. Use synthetic or client-approved sanitized examples in the room; test client data only in the approved client environment
• Security questions → Playbook 7. Don't improvise

• Hand the recording or notes to Viktor: Here are the discovery notes. Give me an order of operations: which department first, which workflows, what access each needs, a proposed pilot sequence and the prerequisites for each step
• Then: Estimate potential time and cost savings per workflow from our measured baseline — label every assumption. Present that, validate it during the pilot, and do not promise the estimate as a guarantee
• Expand when the first workflows meet agreed quality, ownership and adoption checks; adjust the pace to the client instead of a fixed one-department-a-month rule. Starting too broadly can leave workflows incomplete; choose a manageable scope
• Aim for one useful, verified first-week result the client can evaluate

• Draft in Claude or another editor. For new Viktor skills, use lowercase letters, numbers and underscores: client_reporting.
• Match the folder name to the frontmatter name. Keep instructions in SKILL.md.
• Write a precise description of when to use the skill. Load supporting references only when needed.
• Import: upload the skill and supporting files. Ask: "Check compatibility and tool dependencies. Explain any proposed changes, including renaming, before applying them. Don't run the workflow yet."
• Existing Claude skills may need adaptation, not automatic renaming. Test in a fresh thread before relying on them.

• New skill replaces old → review dependencies and recovery copies before retiring overlaps
• On an agreed review cadence: list all skills, flag duplicates and any not used recently → review each with its owner. Do not delete solely for 30 days of inactivity — check seasonal use, dependencies and ownership, and keep a recovery copy, before pruning
• Process changes → review and test affected skills before relying on the changed workflow
• Prefer focused skills; split unrelated workflows and load supporting references when needed
• No one person's opinion as company process without sign-off

• “Show me a plan first, execute after I confirm” — big tasks
• “If a source fails, say so — never fill gaps with estimates”
• “Ask me up to 3 clarifying questions before starting” — vague briefs
• New deliverable → attach 2–3 good past examples

1. Only after one clean manual pass, then verify an actual scheduled run using the intended owner's permissions — not just the manual pass
2. Same thread, with a named timezone, intended cadence, owner, source and output destination: “Run this every weekday at 8:00 Europe/Warsaw time, post in #ops-viktor. If a source fails, say so — never fill gaps with estimates.” Confirm the saved schedule, and record what should happen if inputs fail or credits run out
3. Outbound (email, posts, CRM): “Draft it and ask me before anything is sent” is a workflow instruction, not a universal technical lock. Also check the tool's actual permission/approval controls, and confirm the designated approver can receive and approve the requests
4. Escalation: “Overdue by 7+ days → DM the owner right away”, and name a human owner plus a fallback if the message can't be delivered
5. Fix a recurring task by replying in its output thread — this is a way to request a fix. Verify the saved recurring instructions actually changed and check the next run
6. Day 30: “List every scheduled task, last run, where it posts” → review inactive tasks with their owner, check dependencies, and pause before deleting

• Viktor used as a search box
• Context re-explained every thread
• Vague ask → vague output → blaming the tool

• "Where does the data live?" — "Viktor stores customer data with cloud providers in US regions by default. AI providers may process it in the US or other regions under their terms. Confirm any special residency requirement before uploading data."
• "Will it get things wrong?" — "It can make mistakes. Review important outputs, correct them and verify any saved process change. Do not assume errors stop after onboarding."
• "What does it cost?" — "Show current pricing and the client's balance. Estimate the proposed workflow from representative usage, with assumptions and a budget."
• "Can IT review it first?" — "Yes. Involve IT before access is granted and use the current legal and security documents."
• "Sensitive or regulated data?" — "Do not submit regulated data unless the required written addendum and approved setup are confirmed."

• Never promise savings or results. Describe what Viktor does.
• When an account is closed or we receive a validated deletion request, active production data is typically removed within about 30 days; backups age out through normal rotation within about 35 days, subject to the current Privacy Policy. SOC 2 Type I is an attestation, not a blanket guarantee of workflow safety or legal compliance. SOC 2 report, DPA countersign, EU residency, HIPAA/BAA → route to Viktor support.
• Discuss the controls and unresolved questions with the client; a sent document alone is not evidence of their review.

• Available custom API configurations include Bearer, header-key, Basic, query-parameter and HMAC, plus no-auth requests; verify the required method in the client’s setup flow. The simple manual dialog and a Viktor-created secure form are different routes — confirm the appropriate route in the client's workspace. Do not present any single method as universally compatible with every provider
• An OAuth-only tool needs a supported OAuth connector or a separately verified route — it is not automatically unsupported
• If no supported API route exists, assess the desktop option's availability, capability permissions, device ownership and reliability (Playbook 11) — it is not an automatic fallback
• Prioritize custom connections that support an agreed high-value workflow; verify permitted data, maintenance effort and reliability before committing

• Weekly ops dashboard, 2–3 tools, auto-refreshed
• Status page an agency shares with THEIR client
• Simple tracker or board fed by a scheduled task

• Start with private, authenticated access for internal/client data. Confirm the sharing policy before making anything public
• Test with the intended client viewer, not just the creator
• Check what each app endpoint actually permits and which integration identity it uses — being able to open the page is not the complete data-access test
• Test the actual refresh path and verify client operation before removing specialist access

• Refresh only as often as the use case requires — not by default. Schedule it (Playbook 6): Refresh every weekday at 7:00 [timezone]
• Display the last successful data update, source failures and a stale-data status. Never silently replace a failed pull with zeroes
• Every Space in the handoff doc (Playbook 12): app owner, access manager, integration dependencies, refresh schedule and recovery route

• "Desktop work requires a supported, connected and online device with the needed capabilities enabled."
• "Review the permissions for files, apps, browser access and commands separately. Folder choices do not describe every capability's boundary."
• "Approval depends on the device and conversation settings. I can't promise a separate approval or visible step for every action."
• "Confirm who owns the device and who is allowed to use its connection — a shared client workflow shouldn't depend on my personal laptop."
• "To stop it: pause the workflow, disable the relevant connection or capability, and verify access is actually stopped. Closing the window alone isn't a universal shutdown procedure."