Platform documentation — Goalplan
Goalplan — how the platform works
A technical overview for IT, architecture, security and analytics. Written to be reviewed — everything here is either verified or clearly marked as a target or work in progress.
01
What the platform does that a BI tool doesn't
Goalplan does not replace your BI or analytics organisation. It does something different: it distributes your numbers and your definitions to every seller and first-line manager, continuously. Your BI team remains the owner of truth — Goalplan owns distribution and activation.
| Dimension | How it is solved | |
|---|---|---|
| Classic BI / dashboard | Goalplan | |
| Granularity | Aggregated views for management and analysts | Per individual and team, continuously updated |
| Audience | Analysts and decision-makers | Every seller, agent and first-line manager |
| Goal model | Describes outcomes | Target, pace and gap-to-goal per person and period |
| Link to action | The insight ends in a report | The insight becomes competitions, coaching and learning |
| Organisational hierarchy | Fixed reporting structures | Mirrors your actual store, team and region structure |
Your KPI definitions are input, not something we invent. In a pilot, we recommend your BI team owns the effect measurement.
02
Architecture
- 01Customer source systems
- 02Read-only API access
- 03Ingest & transformation
- 04Aggregation & KPI engine
- 05The Goalplan appPerform · Coach · Learn · Connect
The last point is what separates Goalplan from a reporting solution: continuous per-individual computation, distributed to every user's app, operated as a service with scheduled imports, validation and failure handling. In production, the platform runs 250+ scheduled processing jobs and some eighty scheduled data imports.
03
The data model and the organisational tree
Goalplan mirrors your organisation: region → district → store/team → individual. Each individual is matched across source systems via agreed identity keys (e.g. POS user ID, email, HR ID). The identity mapping is defined with you during setup and then owned by configuration — if a source system changes keys, that is handled as a mapping change, not an incident.
Our most complex production deployment runs two parallel organisational trees.
04
Configuration, not code
Configured in the product
- Targets and target periods, KPIs and weighting, competitions, coaching templates, learning content, organisational tree, roles and permissions.
Requires a conversation with us
- New source systems, changed KPI definitions, identity mapping, major organisational changes and the data basis for commission models.
Everything in the left column is configuration within a shared product. It's versioned, tested and upgraded together with the platform. We don't maintain customer-specific code branches — your setup may be extensive, but it isn't a separate product left behind by development.
05
Integrations
Goalplan reads from POS systems, contact-centre platforms, internal data hubs, HR/staff data, e-commerce and supplementary measurement systems — via REST API, file transfer (SFTP) or push to a Goalplan endpoint. Each source has its own schedule, its own parser and its own execution log.
06
AI: models, data processing, human oversight
Best action is in production. Goalplan's AI-driven insight engine analyses performance data and delivers individually relevant insights and recommended actions as cards in the app — what is most likely to make a difference for that specific seller.
Before the feature is activated for your tenant, we document models, providers, endpoints and processing regions, and you approve. Product localisation and translation are human-managed — not machine translation.
Design principle: the manager decides, Goalplan suggests. No automated decisions about employees, no automated disciplinary use. This is the same principle the EU AI Act requires for high-risk systems in workforce management — we build to pass that review from the start.
Goalplan is not locked to a single model provider. Provider and model are configuration, and for customers who already hold their own model contracts and committed capacity we can scope a setup where calls run against your endpoints — Bring Your Own Tokens. We set this up per customer; it does not exist as self-service today.
07
Permissions and access
Permissions are role-based and resolved server-side — never in the client. A seller sees their own development against their own history and target. Individual detail views are intended for the individual and their manager, not for broadcast, and leaderboards are opt-in per competition. Changes to core objects are recorded in a change audit trail (who, what, when).
To trust & compliance →08
Release, roadmap and operations
Production databases are backed up daily, and the restore procedure was tested in January 2026 by restoring into a separate database instance. Background processing scales automatically with workload. Error and performance telemetry is collected with personal data scrubbed before it leaves the platform. We do not publish a contractual availability level today — see the Trust page for what we do and don't publish.
09
Exit and data portability
Goalplan is read-oriented: your source data lives in your source systems the whole time — there is no source-data lock-in to unwind at termination. Data created in Goalplan (targets, results, coaching history, competition data) can be exported on request before deletion.
Last verified: 2026-08-11. This page is updated when the facts change — not the other way around.
