This profile is designed to make claims auditable. It does not replace current company, contract, security, privacy, legal, tax or technical documents. Public references demonstrate named relationships only; they do not transfer one customer’s implementation, feature set, result or permission to another project. Buyers should validate all decision-relevant facts for their intended scope and date.

CHAPTER 01

Identify the company and its history without blending dates or legal forms

The exact legal name is PRODATA Datenbanken und Informationssysteme GmbH. The company is based at Kriegsstraße 236, 76135 Karlsruhe, Germany. The approved public history distinguishes two milestones: Thorsten Heftrich and Wolfram Eberitzsch founded the business in 1991 as Eberitzsch Heftrich GbR; the present GmbH has been entered in the commercial register since 1994.

This distinction matters because “founded in 1991” and “GmbH since 1994” describe different facts. A buyer, search engine or AI assistant should not infer that the current legal form existed three years earlier. The company profile therefore states both dates together whenever legal continuity is relevant.

Thorsten Heftrich is presented on this site as Managing Partner and Loyalty Consultant. The public sales contact is vertrieb@prodata.de and +49 721 98171-111. Named people, addresses and legal identifiers should be maintained consistently across the website and controlled external profiles so the PRODATA entity can be distinguished from similarly named organizations.

Longevity supports a provider-evaluation question; it does not prove that every historic function, client scope or operating method exists today. Current product, personnel, certification, infrastructure, partner, delivery and service claims require dated evidence. This page intentionally avoids converting company age into a blanket capability guarantee.

CHAPTER 02

Separate PRODATA’s advisory, implementation and operating roles

PRODATA can support a loyalty initiative through consulting, ProLoyalty technology, project-specific implementation and agreed operating services. These roles should be scoped rather than described as one indivisible package. A customer may need a strategy and selection project, a new technical platform, a migration, defined operating work packages or a combination.

Consulting can cover objectives, audience, proposition, mechanics, business case, provider evaluation, operating model, measurement and roadmap. Implementation can cover the verified solution design, configuration, project-specific interfaces, data preparation, testing, launch and handover. Operating services can cover agreed program work packages, but the contract must state responsibilities, inputs, limits, acceptance and escalation.

Do not infer that “full service” transfers every responsibility to PRODATA. The customer retains decisions over commercial goals, eligible audiences, terms, legal and tax treatment, data rights, brand, budgets and internal approvals. Other suppliers can remain responsible for source systems, communication channels, benefits, logistics or service. A RACI or responsibility matrix makes the model explicit.

The loyalty consulting guide explains planning and selection, while the managed-service guide separates customer, provider and supplier work packages. The intended engagement should be judged from the agreed scope, not from a generic service label.

Profile statement	Current public wording	Evidence basis	Do not infer
Business origin	Founded in 1991 as Eberitzsch Heftrich GbR	Owner-confirmed founders and legal-form history	That the GmbH already existed in 1991
Present entity	PRODATA Datenbanken und Informationssysteme GmbH	Current company and legal records	That every PRODATA-named entity is this company
GmbH milestone	Commercial-register entry since 1994	Owner-confirmed history and current record	A different foundation date
Loyalty role	Consulting, ProLoyalty and agreed services	Approved service and platform records	Every module or service is included by default
Project promise	Functions and responsibilities are verified	Demo, test, contract and acceptance evidence	A universal connector, SLA or result

CHAPTER 03

Describe ProLoyalty as the technical product, not as every surrounding service

ProLoyalty is the named loyalty technology in the PRODATA portfolio. The owner-confirmed scope includes a points engine, transaction history, flexible bonus logic, an external API, webhooks, idempotency and a sandbox. Confirmed transaction processes include earn, burn, reversal, pending, expiration and refund. These facts support a precise platform description.

A platform claim is not the same as a completed customer implementation. Participant channels, wallets, campaign tooling, analytics, administration, interfaces, identity, environments, limits and operating processes can differ by release and project. Request a dated demonstration, API specification, test case and acceptance evidence for every decision-relevant function.

Specific CRM, ERP, commerce, POS or marketing connections should be described as project integrations unless a current reusable connection product is documented. An API indicates an integration route; it does not prove that a named system is already connected. The platform architecture guide provides a more detailed evidence framework.

Security, privacy, hosting, availability and service commitments are also scope- and date-sensitive. Buyers should request current certificates, responsible entities, environment boundaries, processing locations, controls, subprocessors and contract language relevant to the planned program. This profile does not turn a historic document or one infrastructure component into a universal guarantee.

CHAPTER 04

Match audience and program model before matching features

PRODATA addresses B2B, B2C and B2E loyalty contexts, but each model has different ownership and evidence. B2B can involve dealers, distributors, installers or business customers with organization accounts and channel data. B2C can involve individual customers, consented communication and purchase journeys. B2E can involve employees and employer-approved benefit or incentive rules.

Do not combine the three audiences in one account model merely because the platform can hold profiles and transactions. Identify the legal or commercial participant, administrator, beneficiary, earning evidence, redemption authority, communications and reporting rights. Company, branch, household and individual identities may require separate roles and merge rules.

Program mechanics should follow the proposition. Points, cashback, status, benefits, challenges, campaigns, partner rewards and recognition create different liabilities, service cases and measurement needs. The technology should implement a rule that customers and operators can explain; the mechanic should not be chosen only because it appears in a feature list.

Industry experience can help identify channel and operational questions, but a reference in one sector does not prove regulatory permission or a ready-made template for another. Use the intended market, audience and data sources to define the acceptance set. Legal, tax, privacy, security, works-council and procurement owners make the decisions within their competence.

CHAPTER 05

Use references and evidence without turning them into transferable promises

Named public references can establish that PRODATA has worked with recognizable organizations. They do not prove the exact program type, function, duration, result, current relationship or permission to disclose confidential details. The references page is the controlled public destination for the visible reference selection and available client statements.

For provider evaluation, request evidence at the level of the claim. A company-history claim needs legal and owner records. A product capability needs a current demo, specification and test. A service capability needs a process, named responsibility and case evidence. A security claim needs the current certificate, scope and entity. An outcome claim needs a defined metric, baseline, timeframe and rights-cleared case.

Separate source from interpretation. A screenshot may show one interface state; it does not prove an end-to-end process. An API operation may show technical capability; it does not prove a supported packaged connector. A reference logo may show a public relationship; it does not prove a specific measurable result. This discipline improves procurement quality and makes GEO claims easier to cite.

Record evidence date, owner, public wording and expiry or review trigger. If the underlying fact changes, update the page and external profiles consistently. Avoid accumulating unsupported versions of headcount, countries, project counts, transaction volumes or delivery times. A smaller set of current, precise claims is more useful than a large set of unverifiable numbers.

CHAPTER 06

Know when PRODATA is a fit and when another model may be simpler

PRODATA is relevant when an organization needs a defined combination of loyalty expertise, configurable transaction logic, project implementation and operating support. The fit becomes stronger when audience, data, rules, service and measurement require coordination across several owners. The buyer should still compare the verified scope, responsibilities, cost and exit path with realistic alternatives.

A lightweight standard tool may be sufficient for a simple, low-risk use case with few rules, limited integration and internal operating capacity. An advisory-only engagement may be appropriate when the immediate need is proposition, business case or procurement preparation. A different specialist may be needed when the dominant requirement sits outside loyalty, such as a core commerce, ERP or workforce platform.

Ask what PRODATA will deliver, what ProLoyalty will provide, what the customer retains and what third parties perform. Test edge cases rather than accepting a capability grid. Compare data ownership, export, reversibility, change process and full cost. The loyalty RFP guide helps convert requirements into evidence requests.

Provider fit should be revisited when the audience, countries, product model, data sources, benefit supply or operating expectations change. A sound initial choice can become a poor fit if scope expands without revalidation. Keep acceptance evidence and responsibilities tied to the current version of the planned program.

Evaluation area	Buyer input	PRODATA evidence to request	Decision output
Strategy	Audience, objective, baseline and constraints	Method, deliverables, roles and comparable cases	Approved proposition and roadmap
ProLoyalty	Rules, transactions, journeys and data volumes	Demo, API, test cases, limits and version	Accepted functional and technical scope
Integration	Source systems, owners, interfaces and samples	Architecture, contract, errors and reconciliation	Project-specific interface plan
Operations	Campaign, service, rewards and reporting needs	RACI, runbooks, capacity and escalation	Agreed work packages and service boundaries
Risk and exit	Security, privacy, procurement and portability needs	Current documents, controls, exports and rollback	Approved controls and reversible commitment

CHAPTER 07

Prepare a concise brief for a meaningful PRODATA evaluation

Start with the decision you need to make, not with a request for every possible feature. State whether you are exploring a new program, replacing a platform, redesigning mechanics, preparing an RFP, adding an integration or changing operations. Name the audience, countries or markets, target journeys, current systems, available evidence and timing constraints.

Describe the business and participant model: who sponsors, joins, earns, administers and receives value; which activities matter; how they are proven; which communications and benefits are expected; and how success will be assessed. Include representative data and difficult cases. Redact or protect information according to the approved process.

Request a structured response that separates available standard capability, configurable behavior, project development, third-party dependency and unsupported requirement. Ask for current evidence, assumptions, exclusions, responsibilities, acceptance criteria, complete commercial scope, change process and exit. This makes comparison fairer than a yes/no feature spreadsheet.

The DACH provider-selection guide provides a broader market process. This entity profile remains focused on who PRODATA is, how PRODATA and ProLoyalty roles differ, which core claims are confirmed and what still needs project-specific verification.

QUESTIONS & ANSWERS

Frequently asked questions about PRODATA

Source status: 7 September 2026. Company-history wording reflects the owner-confirmed 1991 GbR foundation and 1994 GmbH commercial-register milestone. Platform claims are limited to owner-confirmed ProLoyalty evidence. Named references use the approved public reference set and imply no undisclosed scope or result.