Lucy™

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.

Comparison of classic BI/dashboard and Lucy
DimensionHow it is solved
Classic BI / dashboardGoalplan
GranularityAggregated views for management and analystsPer individual and team, continuously updated
AudienceAnalysts and decision-makersEvery seller, agent and first-line manager
Goal modelDescribes outcomesTarget, pace and gap-to-goal per person and period
Link to actionThe insight ends in a reportThe insight becomes competitions, coaching and learning
Organisational hierarchyFixed reporting structuresMirrors 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

  1. 01Customer source systems
  2. 02Read-only API access
  3. 03Ingest & transformation
  4. 04Aggregation & KPI engine
  5. 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.

POSERPCRMWFM / schedulingHRISBI / data warehousePeople counters / footfallNPS / customer surveys
To integrations →

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.