Logisoft Support

How we prioritise

Every request gets a reply within one business day. What happens after that reply depends on how badly the issue is hurting your operation, and on the support level in your plan.

Operations stopped: Nobody can book, file, or release cargo. Vessel or gate operations are blocked and there is no workaround.; Goes to the front of the queue and stays with an engineer until there is a fix or a usable workaround. Plans that include 24/7 priority support are covered outside business hours too.
Degraded but working: A module is slow, an integration is retrying, or a report is wrong, but the operation can still run around it.; Diagnosed first, then scheduled into the work already in progress. You get told which release it lands in.
Question or change request: How-to questions, new user setup, tariff or template changes, and requests for behaviour that does not exist yet.; Answered on the ticket. Change requests get scoped and assigned to a release rather than disappearing into a backlog.

What to include so we can fix it on the first reply

The booking, voyage, or VIN the problem happened on. One real example beats a general description.
What you expected to happen and what happened instead, in that order.
The time it happened and the user account it happened under, so we can find it in the audit trail.
A screenshot of the full window, including any error text, rather than a crop of the message.

Check these first

Platform status

Live uptime for the API, portal, and integration endpoints. If something is down platform-wide, it shows here before a ticket would reach us.

Release notes

What changed and when. Behaviour that looks like a bug is sometimes a shipped change, and this is the fastest way to tell the difference.

Logistics glossary

Plain definitions for the terms the platform uses, from CEU and lane meters to ENS filing and stowage plans. Useful when onboarding new staff.

How we prioritise

Every request gets a reply within one business day. What happens after that reply depends on how badly the issue is hurting your operation, and on the support level in your plan.

Operations stopped: Nobody can book, file, or release cargo. Vessel or gate operations are blocked and there is no workaround.; Goes to the front of the queue and stays with an engineer until there is a fix or a usable workaround. Plans that include 24/7 priority support are covered outside business hours too.
Degraded but working: A module is slow, an integration is retrying, or a report is wrong, but the operation can still run around it.; Diagnosed first, then scheduled into the work already in progress. You get told which release it lands in.
Question or change request: How-to questions, new user setup, tariff or template changes, and requests for behaviour that does not exist yet.; Answered on the ticket. Change requests get scoped and assigned to a release rather than disappearing into a backlog.

What to include so we can fix it on the first reply

The booking, voyage, or VIN the problem happened on. One real example beats a general description.
What you expected to happen and what happened instead, in that order.
The time it happened and the user account it happened under, so we can find it in the audit trail.
A screenshot of the full window, including any error text, rather than a crop of the message.