Onboarding and product knowledge, written from your own docs.

Engineering wikis, runbooks and product specs become learning paths for new hires, support teams and customers. The examples come from your stack, not from a generic textbook.

Learners
Developers, support and sales teams, new hires, customers and partners
Typical topics
Engineering onboarding, Security and data protection practices, Product training for sales and support, Customer and partner academies
Sample module
Handling personal data in our services
A finished lesson as the learner sees it: illustration, lesson text and an audio player.

01  Topics

What we usually cover

  • 1 Engineering onboarding
  • 2 Security and data protection practices
  • 3 Product training for sales and support
  • 4 Customer and partner academies

Any other subject works the same way: from your documents or from a brief.

02  Formats

What works best for these learners

A learner climbs a staircase of five document tiles linked by a dotted path to a flag, starting from a stack of loose pages.

Learning paths

Built from your docs and runbooks, in a sensible order.

A learner at a tablet showing a scenario quiz with an alarm bell, a question card and three answer options, one ticked.

Scenario questions

Drawn from the kind of incidents your teams really handle.

A central cube delivers learning content through plug-and-cloud links to three different apps: a portal, a course platform and a dashboard.

Delivered through the API

Into your own portal, LMS or product.

03  Sample module

Handling personal data in our services

Demo available in Another language? Contact us
  1. 1

    What counts as personal data here

    Personal data is any information that can point to a living person, alone or combined with something else. An email address, a customer ID, an IP address and a device identifier all count. So does a support ticket that names the user. If you can work out who it is, treat it as personal data, even when the name is missing.

    Narration, 0:24
    A developer at a desk looks at a laptop while icons for an email, a user, a fingerprint and a location float above it, linked to a person outline.
  2. 2

    Logging without leaking

    Logs travel further than code: to dashboards, to vendors, to backups. So log the event, not the person. Write the user ID instead of the email, and never print a request body or a token. Before you add a log line, ask what a stranger could learn from it. Mask what you must keep, and set a short retention period.

    Narration, 0:23
    A developer studies a large abstract log window whose lines are partly blacked out, next to a funnel that filters coloured data dots.
  3. 3

    Access and deletion requests

    People can ask what we hold about them, and ask us to delete it. These requests arrive through the privacy form and must be answered within the deadline shown on the ticket. Never search by hand. Open the request in the privacy tool, which finds the records across our services and starts the deletion. Backups are cleared on their normal schedule.

    Narration, 0:22
    A support specialist at her desk moves a ticked document from a filing cabinet drawer towards a bin, with a calendar on the wall.
  4. 4

    Scenario: an email address in a stack trace

    A teammate pastes a stack trace into the team chat. Halfway down, a customer's email address appears inside an error message. What do you do? Do not forward it. Delete the message, tell the teammate, and open an incident for the leak. Then fix the cause, so the code no longer puts the email into the error text.

    Narration, 0:23
    Two colleagues at a desk look at a monitor where one highlighted line carries an email icon under a red warning triangle.

Demos for other sectors

Tell us what your people need to learn.

A 30 minute call is enough to understand whether it fits, and to give you a scope and a price for a pilot module.

Company
ITALIO SRL
Via Emilia Ospizio 16, 42122 Reggio Emilia (RE), Italy