Training and rollout: so the new workflow actually gets used
Technology alone changes nobody's working day. We introduce new workflows inside your company: training on real cases rather than on the manual, key people involved early, support through the transition period and a reachable contact for the questions that come up after go-live.
Rollout and support · net plus VAT
- Training and rollout belong to the fixed price of the implementation
- Training uses your own cases, not sample data
- Support during the first weeks, while adjustments are still cheap
- Refresher training when staff change, via ongoing support
The process analysis as an entry point starts at 1,900 € net and delivers a survey of your workflows, a written report and a prioritised list of measures. Each automation or interface starts at 4,900 € net as a fixed price set after the analysis; training and rollout are part of that fixed price, not a later add-on. Ongoing support with a named contact, refresher training when staff change and adjustments starts at 190 € net per month. All prices net plus VAT; third-party licences and fees are shown separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
The most common reason an IT project changes nothing in a mid-sized company is not the technology. The interface runs, the report adds up, the digital approval path is finished — and the job is still written on a slip of paper, because that is how it has worked for years and nobody explained why a different way makes sense from now on. Rollout is therefore not an appendix at the end of a project but the part that decides whether the whole investment pays off. We plan it in from the start: who is trained, what they train on, who is reachable during the transition and how feedback from daily work flows back into the implementation.
What gets built around the new workflow
Why good technology stays unused
In a running business, every change competes with a way of working that already functions. The old way is slower, less reliable and takes more manual effort — but it is familiar, and it never leaves anybody stranded when things get urgent. As long as the new solution is not noticeably easier than the old habit, the habit wins. There is a second point: anyone who sees a new system for the first time on cut-over day has had no chance to ask questions. Questions that would have taken ten minutes beforehand cost a week of friction afterwards. And a third point is often underestimated: a change announced from above, without the people at the workstations having been heard first, creates resistance — even when the solution is objectively right.
The old way still works
As long as the paper form, the group email or the informal chat remain possible, the new workflow stays optional. During the project we therefore agree which old routes are deliberately closed at which point — and which have to remain as a fallback.
Nobody feels responsible
If the new workflow belongs to no one inside the company, there is nobody to decide when something is unclear. Together with you we name a responsible person per workflow and give them the knowledge that role requires.
Training came too early or too late
Training four weeks before go-live is forgotten by go-live. Training on cut-over day collides with a full working day. We schedule sessions so that only a few days sit between training and live use, leaving room to practise.
Questions go nowhere
Anyone who gets stuck in week two and receives no answer returns to the old way. During the first weeks after go-live there is therefore a reachable contact and a defined route on which questions and change requests are collected.
Training on real cases rather than on the manual
We do not train on sample data or on screenshots but on cases from your own company: the job that was awkward last week, the complaint that touches three departments, the invoice with the unusual payment term. The point is less to explain every button than to walk the new route once from beginning to end — from capture through to completion. Someone who has taken a familiar case through the new system themselves needs no manual afterwards. For exceptions, a short written guide stays at the workplace: one page long, written in the language of your company rather than the language of the software vendor.
Real cases as practice material
Before the session we collect typical and difficult cases from your day-to-day work. Practice happens on those cases in a test environment, so a wrong click has no consequences.
Small groups, short sessions
Three to six people per session, 60 to 90 minutes (project experience). At that size everyone gets to the keyboard themselves, and questions are asked in the room rather than in the corridor afterwards.
At the workplace, not in a training room
Wherever possible we train where the work later happens — same hardware, same permissions, same screens. That exposes obstacles which stay invisible in a meeting room.
A one-page guide, not thirty
For every workflow trained we produce a short guide covering the five to eight steps that matter day to day. The detailed version lives in the process documentation.
Short recordings to look up
On request we record the key workflows as brief screen captures. Anyone joining later or unsure after a holiday watches three minutes and is back up to speed.
Role-specific, not one size for all
The workshop needs different content from accounting, and scheduling needs different content from management. We tailor content and length to the role instead of holding one session for everybody.
Involving key people early
Every company has people the others take their cue from: the foreman who has organised the workshop for twenty years, the colleague who knows the invoicing run by heart, the scheduler everyone calls when something jams. These people effectively decide whether a new workflow is accepted. If they only hear about it on cut-over day, they will at best go along with it and at worst work around it. We therefore involve them from the process analysis onwards — not as recipients of information but as a source of it. They know which exceptions exist, which special cases occur regularly and where an apparently clean rule falls apart in practice.
From affected to involved
People who helped shape a workflow explain it to others of their own accord. We therefore work with a small group from the departments: they review the draft before implementation, are first into the test environment and check the training material for clarity. After go-live this group is the first port of call inside the company — and we keep their back covered during the first weeks.
- Starting point: the new workflow is announced rather than developed together
- Approach: a small group from the departments reviews, tests and co-trains
- Result: questions are answered in-house, not at the next scheduled visit
Co-determination, works council and data protection
As soon as a new workflow produces data from which the behaviour or performance of individual employees can be read, it touches co-determination. That affects more projects than one might assume: a ticket system logs handling times, mobile time recording produces location data, a report on lead times can be broken down to individuals. In German companies with a works council, introducing such technical systems is subject to co-determination (Section 87 (1) no. 6 of the Works Constitution Act). We raise this topic at the start rather than at the end — an agreement reached before implementation costs time; an agreement that has to be caught up afterwards costs time and trust.
We supply the technical basis, not legal advice
- A description of the new workflow in plain language, not a system manual
- An overview of the data produced per step, with purpose and retention period
- A permissions concept per role: who sees what, who may edit, who may report
- A list of technically possible reports and of those actually used
- A proposal for aggregating person-level metrics to team or department level
Supporting the transition period
A rollout plan instead of a cut-over date
Before the switch we agree which areas move in which order, which old route is closed when, and which fallback remains available in an emergency. The plan also records who decides inside the company when a special case comes up that was not discussed beforehand.
Test phase with real data
Before go-live the key group works for a few days in a test environment with an extract of real data. Whatever surfaces there gets changed before the switch — at that point an adjustment is a minor task, after go-live it is a disruption to daily business.
Training shortly before go-live
Training sessions sit a few days before the switch, in small groups and separated by role. Every participant completes at least one full case themselves. Anyone who misses a session gets a catch-up date before the old route is closed.
Supported go-live
On cut-over day and the days after we are reachable and, where useful, look at the screen together. We collect the most frequent questions of those first days and extend the short guide within the same week, rather than reworking it six months later.
Adjustments from daily work
Feedback from the first weeks leads to concrete changes: a field in the wrong place, a mandatory entry that cannot be filled in on the road, a notification that arrives too often. These adjustments are budgeted within the fixed price of the implementation.
Handover to regular operation
At the end of the transition period there is a short review: what works, what still snags, what is missing. The workflow then moves into ongoing operation, with a named contact, monitoring and refresher training when staff change.
Before the switch we agree which areas move in which order, which old route is closed when, and which fallback remains available in an emergency. The plan also records who decides inside the company when a special case comes up that was not discussed beforehand.
Before go-live the key group works for a few days in a test environment with an extract of real data. Whatever surfaces there gets changed before the switch — at that point an adjustment is a minor task, after go-live it is a disruption to daily business.
Training sessions sit a few days before the switch, in small groups and separated by role. Every participant completes at least one full case themselves. Anyone who misses a session gets a catch-up date before the old route is closed.
On cut-over day and the days after we are reachable and, where useful, look at the screen together. We collect the most frequent questions of those first days and extend the short guide within the same week, rather than reworking it six months later.
Feedback from the first weeks leads to concrete changes: a field in the wrong place, a mandatory entry that cannot be filled in on the road, a notification that arrives too often. These adjustments are budgeted within the fixed price of the implementation.
At the end of the transition period there is a short review: what works, what still snags, what is missing. The workflow then moves into ongoing operation, with a named contact, monitoring and refresher training when staff change.
After go-live: taking questions seriously
The decisive weeks come after go-live. That is when the new workflow first meets the cases that appear in no analysis: the customer who wants a collective invoice, the site without mobile reception, the delivery note that has to be added by hand. If those cases stay unanswered, a list in a spreadsheet grows up alongside the system — and with it exactly the duplicate data entry the project was meant to remove. During the first weeks we therefore keep a defined channel open, collect every question in writing and answer it either with an explanation, an addition to the short guide or a change to the workflow. After roughly four weeks it becomes clear which questions repeat; from that we produce the final version of the guide and, where needed, a brief refresher session.
since 2013
experience with business IT
50+
projects delivered (project experience)
60-90 min
typical length of a training session (project experience)
2-4 weeks
supported transition after go-live (project experience)
| Aspect | Rollout by announcement | Supported rollout |
|---|---|---|
| Involvement | Staff hear about it on cut-over day | Key people are involved from the analysis onwards |
| Training material | Vendor manual and screenshots | Real cases from your own company |
| Timing | One joint session, often long before go-live | Small groups per role, a few days before go-live |
| Old routes | Quietly remain in parallel | Closed to plan, with a defined fallback |
| Questions | Get lost in daily business and stay unanswered | Defined channel, collected in writing, answered the same week |
| Co-determination | Noticed once the system is already live | Documents are available before implementation |
| After the transition | The project ends with the handover | Support with refresher training from 190 € net per month |
What training and rollout cost
We do not treat rollout as a separate line item that surprises you at the end. It is part of the fixed price of the respective implementation: when we build an automation or an interface, training, the short guide and support through the first weeks come with it. Only work that goes beyond that is quoted separately — training on a workflow we did not build ourselves, a training series for a larger workforce, or recurring sessions for new staff. All prices are net plus VAT; the binding fixed price is set after the process analysis.
Rollout, training and support
All prices net plus VAT. Every project starts with the process analysis; only then is the fixed price of the implementation set. Third-party licences and fees are shown separately.
Process analysis
The entry point: recording how work really flows, together with the people doing it.
- Conversations at the workstations, not just a look at the systems
- Key people named and involved for each workflow
- Media breaks and duplicate data entry documented
- Prioritised list of measures with sequence and effort
- Note on co-determination-relevant points per measure
Implementation with rollout
An automation or interface including training and the transition period.
- Test environment with real data for the key group
- Training per role in small groups, on real cases
- One-page short guide for the workplace
- Supported go-live and adjustments from daily work
- Documents for the discussion with the works council
Ongoing support
After the transition: stay reachable, retrain, adjust.
- A named contact for questions from your team
- Refresher training when staff change or new colleagues join
- Updates to short guides and recordings
- Adjustments to workflows when requirements change
- Monitoring of the automations and interfaces
All prices net plus VAT. Training and rollout are included in the fixed price of the implementation. Additional training series, training on third-party systems and recurring sessions for new staff are quoted separately, with the amount stated in advance. The full breakdown is on the pricing overview.
How rollouts play out in practice
Illustrative scenarios from typical project courses (project experience), anonymised and without client details.
Technology already in place but nobody using it?
We look at where the rollout is stuck: missing training, unclear responsibilities, or a workflow that does not fit daily practice. The first conversation is free and without obligation.