Give each record a clear job
A customer request can start as a telephone enquiry, become an order and end with a payment. These are related events, not interchangeable records. The enquiry explains the original need. The confirmed order records the agreed goods or services. The payment record provides evidence of the payment outcome. A note saying “paid” in an enquiry is not a substitute for checking the payment record.
Choose a main reference that stays useful throughout the work. If most enquiries become orders quickly, the order record may become the main working record once confirmed. If requests involve several conversations before an order exists, keep an enquiry register and add the order reference later. Either approach can work; the handover rule must be explicit so colleagues know where to look.
Link references without replacing the originals
Different systems may generate different identifiers. Preserve those identifiers and record the relationship between them in an agreed place. Where suitable reference or note fields are available, use them consistently. Otherwise, a controlled handover register can map the request reference to the order and payment references. Limit customer details to what the handover needs and restrict access appropriately.
Avoid forcing a single reference into every field: some fields have a specific purpose or format. Equally, do not rely on a customer’s name alone, because repeat orders and similar names can cause confusion. Agree who adds each link and when. If one request produces two orders or several payments, list each relationship rather than overwriting the first reference.
- Record the main request reference and its responsible team member.
- Add each order reference when the order is confirmed.
- Add the relevant payment reference after checking its recorded outcome.
A hypothetical enquiry-to-payment handover
Hypothetical example: a small catering business receives an enquiry for a collection order. A team member records it as ENQ-042 in the enquiry register. When the customer accepts the agreed selection, the business creates order ORD-118 in its order system. The register links the two references, while the order record becomes authoritative for quantities, collection time and agreed price.
At collection, the customer pays by card. The team checks the payment outcome in the payment service and records the associated payment reference against ORD-118 in its handover register. When the customer later asks about payment, staff follow ENQ-042 to ORD-118 and then to the payment record. This is an example of an agreed manual process, not a claim that any particular products exchange those records automatically.
Separate confirmed capabilities from integration questions
NeroPay offers card terminals and payment services, NeroPOS/ePOS software, NeroWeb online ordering and websites, NeroBooking booking software, and QR payment options. NeroWeb supports direct online ordering. These capabilities do not, by themselves, establish that an enquiry, order and payment share a reference or update one another automatically.
NeroConnect is for connecting software/POS providers and their merchants to payment services. Any particular integration still needs confirmation with the team. Ask which records move, in which direction, what triggers the transfer and how failures appear. Until those details are confirmed, plan a manual handover. Product availability, supported devices, integrations and commercial terms must also be confirmed.
- Ask whether your specific systems and intended workflow are supported.
- Confirm whether references, statuses or both are transferred.
- Agree a fallback for missing updates, duplicate records and interrupted handovers.
Test the trail before relying on it
Walk through one straightforward request and one exception, such as an order changed after confirmation. Check that an edit has not erased the original links. Keep operational status separate from payment status: an order can be ready for collection while payment still needs checking. If records disagree, the team should know which source to consult and who resolves the mismatch.
The observable success check is simple: a colleague who did not handle the request can locate the agreed order, find the related payment evidence and identify the next action without guessing. Your next step is to map one existing workflow on a page, name the authoritative record at each stage and take any unresolved integration questions to the NeroPay team.
GOOD TO KNOW
Common questions
Should customers quote the enquiry reference or the order reference?
Once an order is confirmed, give customers the reference your team uses to find that order. Retain the earlier enquiry link internally so either reference still leads staff to the right record.
Does a shared reference mean systems are synchronised?
No. A shared reference helps identify related records; it does not prove that changes or payment statuses transfer between systems. Confirm the specific integration and its limits.
What if one order has more than one payment?
Keep each payment reference linked to the order separately. Check the individual outcomes rather than replacing them with one unsupported “paid” note.
Which record should staff trust when statuses disagree?
Use the agreed source for that fact: the confirmed order for what is being supplied, and the payment service record for the payment outcome. Assign someone to investigate and correct the mismatch.