Blog
You sell a standard product. Every site is still a project.
You sell a standardized plant, battery block, or process module, and every deployment still behaves like a one-off project. Kord keeps each site's document set forked from the base design, reviewed, and tracked.
Standard products don't stay standard. Every customer site drags in its own OSBL, its own grid connection, its own codes, its own tie-ins, and each one gets its own P&IDs, plot plan, single-line, tie-in list, and Concept of Operations, all forked off the base design and worked through FEED. That's before anyone rolls an improvement back into the base.
PLM has the product side handled: parts, BOMs, CAD, the factory release. The project side (the FEED study, the submittal cycles, the per-site document sets) doesn't map to a part number, so it lands in SharePoint folders, copied directories, and reply-all approvals. And things get through.
Kord is the system of record for the companies stuck between product and project. Each deployment forks the base design, every change runs through a review session with visual diffs, the AI checks the set for drift, and transmittals record which revisions actually went to which customer.
This is you if
- A base design gets forked and customized for every customer site.
- Delivery runs on FEED-style submittal and response cycles.
- The document set gets handed from sales to engineering to commissioning, and context leaks at every handoff.
- PLM has your parts covered, but the deployment documents live in SharePoint and email.
- You've sent a customer two documents that didn't agree with each other.
How Kord fits
Four parts of Kord do the work:
- Folder forking - each site branches from the base design with the relationship recorded. Pull base improvements into the forks; push what you learn on a site back into the base.
- Review sessions - every change is reviewed against a visual diff, with sign-off pinned to exact revisions before anything publishes.
- AI consistency checks - change one value and Kord reads across the set to find the documents still quoting the old one.
- Transmittals - named snapshots of what was approved and sent to each customer, with issuer, date, and a trail.
Common questions
We already run PLM for the product. Why add Kord?
Keep PLM for parts, BOMs, and CAD. Kord takes the thing PLM was never built for: the per-site engineering document sets, the P&IDs and specs and calc sets and submittal packages your team is currently herding through SharePoint folders and email. They sit side by side.
How does Kord handle per-site variants of a base design?
Folder forking. Each deployment forks the base set without copying it, and the fork stays tied to the base, so you can see what a given site changed, pull base updates into active forks, and push a site fix back. A copied folder does none of that; it just sits there getting stale.
Do our files have to leave SharePoint or Drive?
No. Kord syncs on top of SharePoint, Google Drive, and Egnyte. The files stay where they are; Kord adds the version control, the visual review, and the approval record on top.