This Is Not an “AI Strategy” Story
Inside a container shipping software department, AI does not show up as a strategy deck.
It shows up as a very practical question:
Can this help the team move faster without breaking the operation?
For me, working as an AI PM in container shipping software, this is the real test.
Not whether we can build a chatbot.
Not whether we can create a nice demo.
But whether AI can help the people around Booking, Documentation, Shipment Visibility, BA work, QA, and engineering reduce the repetitive work that slows everyone down.
Because in shipping software, the difficult part is rarely just the screen.
The difficult part is the workflow behind the screen.
Where AI Actually Fits in a Shipping Software Team
From my perspective, AI adoption in this domain usually fits into three layers:
- Workflow assistant
- Document and data structuring
- Decision support based on business rules
The mistake is jumping directly to full automation.
Shipping has too many exceptions for that.
A better approach is to let AI support the human first, then gradually automate when the data and rules are stable enough.
Real Workflow Example 1: Documentation Staff
Documentation teams live with many small but painful checks.
A customer submits booking information. Then later, the team needs to prepare or validate documents such as Shipping Instruction, Bill of Lading draft, invoice-related documents, certificate documents, or other required documents depending on lane, cargo, customer, and local regulation.
A useful AI feature here is not “generate all documents automatically.”
That sounds good in a demo, but it is risky.
A more realistic feature is:
AI helps identify which documents are required, then pre-fills the first draft using booking data.
For example, based on the booking data, routing, commodity, shipper, consignee, and port pair, the system can suggest:
- Required document list
- Missing information
- Fields that can be pre-filled from booking
- Fields that still require human confirmation
- Inconsistency between booking data and document draft
This is useful because the documentation staff is still in control.
AI does not become the final approver.
It becomes the assistant that reduces repetitive checking and prepares a better starting point.
The value is not “zero-touch documentation.”
The value is fewer missing fields, fewer back-and-forth emails, and faster document preparation.
Real Workflow Example 2: Booking Customer Service
Booking customer service has a different kind of pain.
They spend a lot of time answering questions like:
- Why is my booking on standby?
- Can I amend this booking?
- Why can’t I submit SI?
- Has this booking been confirmed?
- What is blocking the next step?
The issue is not that booking staff do not know the answer.
The issue is that the answer is often spread across multiple places: Booking status, vessel allocation, customer profile, documentation status, operation remarks, internal rules, and sometimes ERP-side handling.
This is where AI can become very useful as an internal assistant.
For example, when a customer asks:
Why is my booking still on standby?
Instead of forcing the booking staff to manually check multiple screens, the AI assistant can summarize:
Booking is currently on standby because allocation is pending for the selected vessel/voyage. SI has not been submitted yet. No document hold is detected. Suggested reply: inform customer that the booking is pending space confirmation and advise them to wait for confirmation or provide alternative sailing preference.
This does not replace the booking staff.
It helps them investigate faster.
The staff still decides what to send to the customer, but the turnaround time becomes much shorter.
To me, this is a much better use case than a public-facing chatbot that gives generic answers.
In shipping, context matters.
The assistant must understand booking status, workflow stage, and business rules.
Without that context, it is just another FAQ bot.
Real Workflow Example 3: IT BA and Product Team
AI can also help inside the software development department itself.
An IT BA or PM often works with messy inputs:
- Stakeholder meeting notes
- Customer complaints
- Operation feedback
- Existing system behavior
- Business rules from different teams
- Release scope discussions
The painful part is turning all of that into something engineering and QA can actually use.
AI can help by creating the first structured draft:
- PRD
- User stories
- Acceptance criteria
- Test scenarios
- Open questions
- Dependency list
- Impacted modules
For example, if the business says:
We should limit consignee authority on booking actions when booking reaches export stage.
AI can help turn that into a clearer requirement:
- If booking stage = Export
- Then consignee cannot edit booking
- Consignee cannot submit SI
- Consignee cannot request amendment
- Booking party and carrier staff permissions need separate handling
- Impacted modules: Booking, SI, Amendment, Notification, Audit Log
This is where AI is very practical.
Not because it replaces BA thinking.
But because it gives the BA a structured starting point, so the human can focus on logic, edge cases, and stakeholder alignment.
Where Most AI Efforts Fail
Let me be honest.
My team and I also learned this the hard way.
At one point, we tried to build a documentation hub — something close to a central knowledge base that could later support RAG-style search and AI assistance.
The idea was good.
A central place for documentation, business rules, process knowledge, and system references sounds exactly like what AI needs.
But the execution was harder than expected.
The problem was not the AI model.
The problem was the foundation.
Some data was inconsistent. Some documents were outdated. Some process knowledge lived only in people’s heads. Some information was scattered across Google Drive, Confluence, emails, meeting notes, and different team folders.
Even worse, the pipeline to keep that knowledge clean and updated was not strong enough.
So we had a classic AI adoption problem:
We wanted an intelligent layer, but the knowledge layer underneath was not reliable enough.
That is where many AI projects fail.
Not because the demo is bad.
But because production usage requires trust.
And people will not trust AI if the source data is messy, outdated, or impossible to verify.
What I’d Do Differently as a PM Starting Today
If I were starting that documentation hub again, I would not begin with the RAG system.
I would start smaller and more boring.
First, I would define the knowledge structure:
- What type of content belongs in the hub?
- Who owns each type of content?
- How do we know if it is still valid?
- What is the review cycle?
- Which content is source-of-truth?
- Which content is only reference material?
Second, I would narrow the first scope.
Instead of trying to cover all documentation knowledge, I would pick one workflow, such as:
- Booking standby reason handling
- SI submission validation
- Booking amendment permission
- Document requirement by lane
Third, I would make the content AI-ready before making it AI-powered.
That means creating structured, clean, and version-controlled knowledge first.
Only after that would I add the AI assistant layer.
The better sequence should be:
- Clean the workflow
- Structure the rules
- Define ownership
- Build the knowledge hub
- Add AI search or assistant
- Measure if it reduces real manual work
This is less exciting than saying “we are building a RAG system.”
But it has a much higher chance of surviving production.
The Pattern That Actually Works
The best AI adoption pattern I see for container shipping software is:
Assist first. Automate later.
For documentation staff, AI should help prepare and validate documents.
For booking staff, AI should help investigate booking status and suggest replies.
For BA and product teams, AI should help structure requirements and identify missing logic.
For engineering teams, AI should help accelerate development, testing, and documentation — but still within clear review control.
The common point is simple:
AI should reduce the time people spend searching, checking, rewriting, and repeating.
That is where the real value is.
Final Thought
AI adoption in container shipping software is not about replacing operators, documentation staff, booking teams, BAs, or PMs.
It is about making the software department and operation teams work with better context.
The winning AI features will not be the flashiest ones.
They will be the ones that quietly help people answer faster, prepare documents better, write clearer requirements, and reduce avoidable rework.
In this industry, that matters more than a fancy demo.
Because demos do not move containers.
Reliable workflows do.