Customer Support Contact Sales

iGaming operations: Features

Use ZavERP’s CRM, boards, and workflows to organize player-facing work. Configure records, processes, and connections for your product, with customer context and team tasks in one workspace.

Customer context

Keep customer context together

Use the shared CRM to maintain customer profiles and contact history. Adapt record fields to the information your team needs for player-facing operations.

Client profiles

Keep names, phone numbers, email addresses, tags, manager, and notes on one client record. Maintain context before starting the next conversation.

Recorded conversation history

Review messages stored on the client record and add conversation entries. Channel labels describe the source; live synchronization depends on an implemented connection.

Daily operations

Organize follow-up on boards

Track requests and operational tasks on Kanban boards. Add descriptions, priorities, and associated customers, then move cards through the stages your team uses.

Cards with useful context

Give a card a title, description, priority, and linked counterparty. Keep the next piece of work understandable to colleagues before moving it to another stage.

Saved stages and ordering

Drag cards between columns and reorder them within a column. Changes are saved on the server; a failed move is reverted instead of silently losing the previous position.

Connected business processes

Configure processes and product connections

Build document-based workflows for your operational steps. Connections to external gaming and payment systems are configured for your product and its data flows.

Operational workspace rather than a game engine

Player wallets, game providers, wagering, bonuses, and regulatory checks are product-specific integrations. The current foundation covers customer records, team work, and configurable ERP processes.

Structured field definitions

Define text, numbers, dates, choices, and related records in the data model. Add localized labels and hints so the same structure is understandable in different languages.

Actions with defined behavior

Build workflows from the available executor functions and their parameters. More complex behavior needs a supported action rather than an unchecked promise that any block will run.