Morning check-in01
Before
Minutes of manual checks for each child
After
→Seconds for a standard check-in
5+ readiness conditions checked automatically
Back to cases
Demo data · personal and financial details replacedOne connected operational history
Childcare & education · ERP evolution
An internal ERP that kept evolving as the camp business changed
Based in Latvia and welcoming children from 25+ countries each year, Aktivists needs more than a booking database. Over successive seasons, its ERP grew into a connected operational platform for documents, child data, payments, attendance, check-in and financial visibility.
DocumentsQuestionnairesCheck-inFamily dataWalletPlanningFinance
- Sector
- Childcare & education
- International reach
- Children from 25+ countries each year
- Starting point
- An existing custom ERP
- Engagement
- Long-term system evolution
- Focus
- Bookings · compliance · attendance · finance
How we joined the project
The system already worked. Its development could not stop there.
Aktivists came to IC Studio with a custom ERP already in daily use. The task was not to replace it from scratch, but to understand the existing logic, unblock its development and preserve the processes the team already relied on.
Running camps for an international community adds detail to every application: languages, individual needs, documents, authorised adults and planned attendance all have to remain connected. The system had to absorb new requirements season by season without breaking the operational continuity around children and families.
01
Understand
02
Preserve
03
Rebuild
04
Keep evolving
Starting point · application flow
One shared view of every application in motion
The Kanban made each application visible at its current stage — from documents still required and payments awaiting action to confirmed registrations. It became the operational core to which the later modules were connected.
Documents due
Awaiting payment
Confirmed
System evolution
The business kept changing. The ERP had to keep learning its logic.
Each stage began with a real operational constraint. The response was not a detached feature, but another connected part of the same working system.
The change is visible in the work, not only in the interface
These are operational transitions rather than invented performance percentages. They show what the team had to do before and what the system now handles or makes visible.
Documents02
Before
Seasonal paper contracts to sign and archive
After
→One searchable digital record
Parties, status, date and time retained
Questionnaires03
Before
Repeated requests across duplicate records
After
→One valid questionnaire for the year
A new version is requested the following year
Family data04
Before
Separate records created by repeat applications
After
→One connected family history
Children, orders, payments and visits remain linked
Attendance05
Before
Selected days stored in individual order notes
After
→One daily attendance plan
Expected numbers visible for every date
Finance06
Before
One combined total for different service types
After
→Main and additional services shown separately
Fictional 2026 demo data
The check-in flow
A quick arrival, with a complete handover record behind it
The public screen remains simple for parents. Behind it, the ERP retains the authorised person, time, signature and the order conditions that made check-in possible.
Demo data · personal and financial details replaced01
Find the child
The parent enters the child’s name and sees the matching registration.
Demo data · personal and financial details replaced02
Confirm the handover
The authorised person, time and signature are captured before confirmation.
Demo data · personal and financial details replaced03
Keep the history
Check-in and check-out events remain available as one chronological record.
Exception handling
Only exceptions reach the administrator
Payment, signed documents, a current questionnaire, authorised persons and the attendance plan can be checked automatically. If one condition fails, the parent receives a short code while the administrator sees the reason.
5+ conditions · seconds, not minutes
Demo data · personal and financial details replaced
Demo data · personal and financial details replacedOne connected history
Data stopped following applications and started following the real family
Consolidating duplicate records changed more than the database. It made loyalty, payments, documents and visits readable as a continuous relationship across children and seasons.
Demo data · personal and financial details replacedDemo data · personal and financial details replaced
Demo data · personal and financial details replacedPlanning
Individual days became operational capacity
Days selected during booking feed the attendance plan and registration view. The team can see expected numbers for each date instead of collecting notes from individual orders.
Before
Notes in each order
After
→Daily plan in one view
Demo data · personal and financial details replacedFinancial visibility · 2026
The financial picture evolved with the service model
Service invoices made transfers, excursions and other additions visible alongside the core camp product. Management can read both without losing the combined view.
Demo view · financial figures obscured
Demo data · financial figures obscuredBusiness value
A system that carries the operating model forward
01
A family record carries history across children, bookings and seasons.
02
Readiness checks happen before a child is handed over.
03
Attendance plans connect sales with staffing and capacity decisions.
04
Payments, wallet movements and service invoices remain traceable.
05
The ERP can absorb new operating models without replacing the whole system.
Project insight
“The strongest internal systems are not finished once. They keep absorbing the logic the business learns over time.”
Let’s talk
Discuss your situationWhen an internal system no longer reflects how the business works, the next step is understanding what changed.
We can explore which workflows should be preserved, connected or redesigned before deciding what to build.