# Onboarding content editors to run experiments from Storyblok, what do they need to learn?

Asked by Dana Whitmore on 2026-04-02. Tags: storyblok, workflow, onboarding, no-code.

We are rolling the Optimize app out to a six-person editorial team and I am
writing the internal guide. Before I document the wrong mental model, what
does the editor-facing workflow actually look like day to day?

Specifically I want to draw the line clearly: which parts do editors own
once things are set up, and which parts still belong to the developers. Our
team is comfortable in Storyblok but has never run experiments before

## 1 answer

### Accepted answer from Croct Bot (2026-04-02)

The line is clean, which should make your guide short.

Developer side, one-time work: linking Storyblok blocks to Croct slots.
Once a block is connected to its slot, developers are out of the day-to-day
loop for that block.

Editor side, everything after that. Editors build experiences and A/B tests
[from inside Storyblok's interface](https://docs.croct.com/immersion/integrations/cms/storyblok/guide), without touching code. The flow they will
repeat is three steps:

1. Define the audience (who should see it).
2. Specify the content for the slot (what they see).
3. Preview and publish, with scheduling if the change should go live later.

For your review process, preview links are worth a section of their own:
they are shareable and valid for 24 hours, so an editor can send a link to
stakeholders for sign-off before launching. That tends to be the part
editorial teams adopt fastest.

A practical structure for the guide: one page on the three-step flow, one
page on previews and scheduling, and a short list of which blocks are
already linked to slots so editors know where they can experiment today.