From separate applications to a coherent system
Digitalisation did not start with technology. It started with the real journey of goods and information.
Flowers Market Holland is a B2B distributor of flowers, plants and accessories for professionals. In this kind of business, the same information moves through many contexts: a customer registers and receives access, buys in the warehouse or online, products arrive from suppliers, they are received and labelled, inventory changes, orders need clarification and documents reach accounting. When every stage is treated in isolation, people copy the same data between forms, email, files and applications.
The project grew gradually. AYSA and Web-Development started with concrete operational problems and built components suited to where work happens: web interfaces for customers and back-office teams, warehouse tools, NEXUS ERP integration, document automation and a WhatsApp conversational channel. Flowers Market remained the source of commercial rules and operational validation.
The outcome is not a new ERP intended to replace everything. It is an operational layer that connects systems and makes processes easier to follow. Some decisions can be automated; others require human confirmation. Some data can be shared with customers; other data must remain internal. The architecture is built around these boundaries.
Ecosystem map
Every application has a role. Value appears in the connections between them.
Customers see the card flow, webshop and Oxalis. The team uses administration, receiving, labelling, ordering and communication tools. NEXUS remains the system of reference for relevant entities and accounting documents.
01 · Customer relationship
From registration to a commercial identity used consistently.
The card is not just an image with a code. It connects a person, a company, purchasing rights and the systems that must recognise the relationship.
Onboarding for companies and individuals
The registration flow collects required data, documents and agreements in a guided journey. For companies, the system keeps the business, representative and delegates separate. Individuals follow different identification rules and face different duplication risks. These distinctions are not left to a single generic field.
Documents are checked before the process is considered complete. Contract, privacy information and identification documents have distinct states. If a mandatory step is missing, the system does not display artificial success. Unclear cases move to review instead of being automatically “fixed” through assumptions.
Card, company, delegate and ERP correspondent
Behind the card is a relationship between several entities. The system keeps its local identity and confirmed NEXUS references, uses deterministic retry rules and reads the outcome after a write. A technical retry must not create another customer, another delegate or a different card code.
Confirmation is not based solely on a successful server response. The flow interprets the business result, keeps separate states for each component and distinguishes recoverable situations from cases requiring staff intervention. Final email delivery and activation are tracked as separate stages.
Managing the relationship after registration
The back office gives the team access to the customer profile, documents, cards, communications and integration status. Sensitive operations are protected through roles and confirmations, while important actions remain auditable. Customers do not need to understand the internal structure; the team needs full context to resolve exceptions correctly.
This flow also supports later webshop access. The professional customer starts from a verified identity, and digital channels can reuse the same commercial relationship without a parallel registration. The guide to digital B2B customer onboarding explains the general model in more detail.
| Stage | What must be preserved | Where people intervene |
|---|---|---|
| Registration | Structured data, agreements and documents attached to the correct request | Clarify incomplete or conflicting information |
| Identity | Company, person and delegation as distinct entities | Resolve ambiguous matches |
| Card | Permanent code, state and customer relationship | Confirm exceptions that cannot be reconciled |
| ERP | Confirmed references and a read-back result | Validate unusual business cases |
| Access | Activation and delivery tracked separately | Support delivery or association failures |
02 · Internal operations
Receiving, inventory and labelling need to speak the same language.
In floral distribution, products are physical, lots move quickly and packaging matters. Software must follow the goods rather than invent a parallel reality.
Product identity before automation
The same product may appear with different names, codes or descriptions in supplier documents and the internal system. Before a line can be imported or labelled, the system must determine whether the product exists, whether the match is safe enough and what information belongs to the received lot.
Confirmed mappings can be reused, but text similarity alone is not an accounting fact. When a code or product attribute is insufficient, the line remains visible for validation. This protects inventory and documents from errors that would be much harder to repair after receiving.
Labelling starts from receiving
Labels are produced in the context of a receipt and confirmed products. A session retains its invoice or source document, lines, quantities, product associations and printing history. Operators can see what was prepared, what was printed and where a controlled correction is required.
Printing is adapted to the warehouse environment and can use dedicated tools. Warehouse staff should not be forced to work like accountants, and the ERP should not become a printer interface. Each component exposes the actions needed by its role while keeping the same product and receipt identity.
Useful stock for staff, safe information for customers
Aggregated inventory helps the team prepare and validate requests. Exact internal quantities, however, should not be exposed automatically in every channel. Customers can receive qualitative availability bands because stock can change between conversation and final confirmation.
The same discipline applies to price guidance and packaging. The system can present a reference or known options, but the team confirms the final commercial price and physical availability. Read the detailed guide to warehouse digitalisation, labelling and traceability.
03 · Accounting and NEXUS ERP
An external invoice becomes verifiable data, not another file to retype.
Automation handles repetitive work without hiding ambiguous lines behind a successful import message.
Supplier invoices may arrive by email, downloaded files or controlled uploads. The system identifies the document, extracts available information and creates a draft. Number, date, supplier, lines, quantities, currencies and values remain attached to the source so reviewers can return to the original document.
Every line must be associated with the correct product. A confirmed mapping can move forward. A new or conflicting description remains for an operator to resolve or for controlled product creation. Automation prepares the decision; it does not disguise uncertainty.
After validation, the system can prepare and import the required documents into NEXUS. Stable identifiers, existence checks and result read-back reduce the risk of duplicate imports during retries. An unclear integration response leaves the draft in an investigable state.
The model is semi-automatic where supplier reality does not support complete automation. This means that people approve the exact exceptions for which they hold commercial or accounting context, while the system handles repeatable steps.
See the full approach to supplier invoice and NIR automation and the comparison between standard ERP and custom software.
04 · Orders and logistics
An order must reach the warehouse with the same meaning it had for the customer.
A new channel adds little value if the team must retype the order and reconstruct its context.
Several channels, one operational model
Customers may plan purchasing in the webshop, talk to the team or use Oxalis. These entry points have different interfaces, but products, quantities, packaging, requested dates and notes must reach a common structure. Otherwise every channel creates a separate queue and another source of misunderstanding.
An assisted order retains customer identity and a verifiable summary. It is not treated as a final sale before the team confirms availability and terms. In fast-moving inventory, separating request, draft and confirmation protects both the customer and the operation.
Preparation, packing and handover
Once accepted, information must be usable by the people preparing the goods. The selected product, packaging, quantity and date should not need to be deciphered from a message thread. Internal workflows organise orders, preparation tasks and the states that show what happens next.
Logistics uses the same references to avoid re-entry. Systems for documents and transport can be connected to the order and customer where needed. Not every operation must be fully automatic; transfer between roles must be explicit, traceable and reversible when a correction is required.
Warehouse feedback returns to the system
If an item is unavailable, packaging differs or the customer requests a change, the canonical flow must receive the update. This allows the commercial team to communicate from the same reality as the warehouse. Read more about connecting orders, inventory, warehouse and delivery.
05 · Oxalis
An AI colleague that knows the business rules and knows when to call a person.
Oxalis is Flowers Market's conversational WhatsApp channel. Customers can write naturally, send voice notes or images and build a request without learning a rigid form.
Natural language
Separates products, colours, quantities, lengths and notes from text or voice.
Catalogue and packaging
Uses commercial vocabulary and asks when a product has several options.
Inventory guidance
Reads structured data and communicates availability without exposing exact internal quantities.
Explicit confirmation
Keeps the request as a draft and does not present it as confirmed without customer approval.
Human operator
Escalates questions that require judgement while preserving context and controlled return.
Controlled learning
Stable answers may become knowledge proposals only after human review and approval.
Architecture principles
Automation is safe when it recognises the limits of its certainty.
One canonical flow
The same entity or document should not be written through several implementations with different rules.
Retry without duplication
Operations use stable identity, locking where necessary and checks before and after writes.
Read-back and reconciliation
A technical response is not the business result. Important state is read back and mismatches remain visible.
People approve exceptions
Operators intervene where data is missing, a conflict exists or a decision has a sensitive effect.
Role-based context
Customers, warehouse, accounting and administrators see different information suited to their tasks.
Observability without exposure
Events and states support investigation without turning personal or commercial data into public reporting.
Read the guide to building operational software without breaking existing processes.
How it was built
An operational programme delivered through verifiable steps, not a big-bang replacement.
Discovery followed real work
Each intervention began by observing who receives information, where it is completed, which checks are performed and what evidence allows the next person to continue. The team considered normal cases alongside incomplete documents, products that are difficult to identify, interrupted attempts and situations requiring a commercial decision. A broad request such as “automate supplier invoices” or “issue a customer card” therefore became a journey with defined inputs, states, responsibilities, exceptions and an accepted outcome.
This distinction matters because a written procedure usually captures the intended route, while actual work contains the handovers and corrections that software must support. Discovery recorded the terminology used by operators, the files and messages that transfer context, and the point at which a person no longer trusts an automated result. Those observations shaped both the interface and the integration contract.
Every important fact received an owner
Customers, delegates, products, stock positions, invoices and orders cannot be managed safely if every application invents another identity. For each entity the programme identifies the system of record, the stable correlation key and the roles allowed to make a change. Dedicated interfaces may collect or display information without becoming competing sources. When a write reaches NEXUS, the local application preserves the relationship and reads the functional result back before presenting a confirmed state.
This ownership model also prevents convenient shortcuts from becoming permanent inconsistencies. A label interface should not silently redefine a product, and a conversational assistant should not hold its own private version of availability. Where a mismatch cannot be resolved deterministically, the system creates a visible exception for the authorised person rather than guessing.
Sensitive writes use one controlled route
Important integration operations are not scattered across screens and scripts that can behave differently. They pass through canonical services with validation, an idempotency key, redacted logs and reconciliation. If the network interrupts the response, a retry does not simply assume the first attempt failed. The service checks the known state, uses the same operation identity and avoids creating a second customer, document, goods receipt or order.
Read-back is especially important when technical success and business success are different. An HTTP response may show that a request was received while the ERP later rejects a functional rule. The interface therefore distinguishes “prepared”, “sent”, “accepted” and “requires review”, so operators can understand what actually happened and what action is safe.
Interfaces match the role and place of work
A customer submitting documents for a card, a warehouse operator printing labels, an accountant checking an invoice and a colleague taking over an Oxalis conversation do not perform the same task. They still need the same entities and states, expressed in a form appropriate to that moment. The interface design limits unnecessary decisions, makes the next safe action obvious and keeps exceptions visible without disclosing information the role does not need.
This is why the ecosystem is not a single oversized back office. The card journey, warehouse tools, accounting review and WhatsApp conversation each have a focused surface. Integration underneath them maintains continuity, while permissions and audit trails preserve the boundaries between customer access, operational action and administrative control.
Pilots, read-back and reconciliation preceded scale
Deliveries can be validated vertically: one real input reaches a final outcome that can be read again. Testing covers the normal path, ambiguous data, retries, double clicks, functional errors and recovery after interruption. For accounting or commercial effects, the technical completion of a request is not enough. Confirmation comes from business state; differences enter a reconciliation queue or an explicit human review.
A limited pilot also creates a safer feedback loop. Operators can point out where a state does not match their language, where the interface adds work or where a frequent exception was missed. Rollout expands only after monitoring, permissions, queues and rollback are understood. This keeps learning inside a controlled change instead of turning production users into the test plan.
Documentation remains useful after launch
Rules, identifiers, states and acceptance criteria must remain understandable when people or suppliers change. Documentation therefore records contracts between systems and operational procedures, not only code structure. It explains what happens when a supplier modifies a file, a product cannot be mapped, a write times out or Oxalis needs an operator. This shared memory lets the ecosystem evolve without rediscovering the same risks at every release.
What the system enables
Fewer breaks between moments of the same process.
Without publishing internal indicators or promising transferable results, the structural effect is clear: customer data can follow a coherent verification journey; receiving can feed labelling; an invoice can become a draft ready for review; a conversational order can reach staff in structured form.
The system reduces the need to reconstruct context at every handover. It makes exceptions visible, separates “prepared” from “confirmed” and gives the team a better starting point. Actual benefit must be measured through time, errors, adoption and service quality, not inferred from the number of features.
The project continues to evolve with Flowers Market processes. Supplier rules change, new products appear, teams learn from exceptions and customer channels mature.
For management, connected systems also clarify responsibility. A case can be seen waiting for customer information, product mapping, accounting validation, order confirmation or operator intervention. Visibility does not remove exceptions, but takes them out of isolated messages and turns them into work that can be followed and assigned.
For staff, value appears when corrected information does not need to be entered again at every stage. Stable identifiers, explicit states and action history reduce ambiguity during a handover. People retain authority over sensitive decisions while receiving the context and tools required to make those decisions more consistently.
For customers, the ecosystem aims for continuity. Data submitted during onboarding can support later access and account administration, while a commercial conversation can progress towards a confirmed order without promises based on stale information. The surface remains simple because validation and operating rules are handled rigorously underneath.
Lessons for other B2B companies
Do not automate the organisational chart. Automate the information journey.
- 01
Start with one important entity
Customer, product, order or document needs a clear identity before automation can be trusted.
- 02
Separate the main flow from exceptions
Build the frequent path first and keep a controlled route for rare situations.
- 03
Integrate before replacing
A custom layer can bridge the gap between standard software and company-specific work.
- 04
Design for the place where work happens
Warehouse staff, accountants and WhatsApp customers need different interfaces over the same reality.
- 05
Measure adoption and outcome
A feature being present does not mean the process improved. Measure use, time, exceptions and staff feedback.
Use the guide to which processes to connect first in a B2B distribution company as a starting framework.
Explore the public systems
Customer-facing proof remains at Flowers Market. AYSA and Web-Development document the delivery approach.
Frequently asked questions
What can another company reuse from this project?
Does Flowers Market use one application for every operation?
Not as a monolith. The ecosystem connects interfaces and services suited to each role, while NEXUS remains the reference for relevant data and documents. Consistency comes from shared identities, rules and integrations.
Why was custom software needed when an ERP already existed?
The ERP handles standard processes, while customer registration, cards, warehouse experience, supplier documents and WhatsApp conversations have specific requirements. Custom software bridges these gaps without copying the entire ERP.
Are supplier invoices and NIR documents fully automated?
Repeatable steps can be automated, but new lines, uncertain matches and exceptions remain under human validation. The goal is a correct draft and less retyping, not the removal of accounting control.
Can Oxalis see exact stock and confirm orders alone?
Oxalis uses structured data to communicate qualitative availability without exposing exact internal quantities. Requests remain drafts, customers confirm explicitly and the Flowers Market team validates physical goods and final terms.
Does Oxalis replace Flowers Market operators?
No. It handles questions and structures requests where sources and rules are safe. When judgement is required or a customer requests a colleague, the conversation can be transferred with its context.
How does the agent learn from staff answers?
A stable human answer may generate a redacted, deduplicated proposal. It never becomes published knowledge automatically; an administrator reviews, edits, approves or rejects it.
Can the Flowers Market system be copied to another company?
The principles can be reused, but the implementation should not be copied mechanically. Every company has different roles, data sources, integrations and exceptions.
How does a similar project begin?
With an inventory of processes, systems and moments where information is re-entered or lost. We choose an area with clear operational value, define the current state and acceptance criteria, and then build in testable stages.