SetuVault holds the controlled record of a project's documents from the first registration to the approved-for-construction issue, with every move attributable and time-stamped.
The register is the spine of the project, so it has to be right every time someone opens it.
Reviews follow the rules agreed at the start of the job, and they keep following them when people are busy or on leave.
Every open item has an owner and a clock, so a late response is visible long before it turns into a dispute.
Anything that leaves one company for another goes out on a numbered record with a date and a list of recipients.
The history of a document is written once and kept exactly as it happened.
Each company sees its own part of the project and nothing more.
Vendors and clients keep their own drawing numbers, and the project keeps its own. Both live on the same document.
Project administrators run the project from screens, not from requests to a developer.
Help is asked for, tracked and given without leaving the portal.
Finding a document should take one keystroke, and knowing where a project stands should take one page.
Every document has one number that is never reused. Exactly one revision is current at any moment. The register shows each document by its current revision, with the file's program icon, state and owner.
On most projects the register is a spreadsheet that one person keeps alive. Here it is the system itself. When a revision is issued, the register changes for everyone at the same moment, and the earlier revision is still there when someone asks what was approved last month.
Every vendor arrives with a numbering system of its own, and nobody wants to renumber a thousand drawings. SetuVault keeps the vendor's number as the document's external reference, right beside the project number.
The register shows both, one under the other, and the search box finds a document by either. A controller who receives a vendor drawing can look it up by the number printed on the title block and land on the project record straight away. Clients' own references work the same way.
Each project adopts a workflow template and keeps its own copy. For every step you choose who is assigned, by role and discipline, and what happens for each review outcome. Every automatic move follows the same rules and audit trail as a person's move.
Each rule reads like a sentence on the screen, for example who receives a drawing after an approval with comments, and a document controller can change it without calling anyone. If a rule cannot find a person to assign, the document waits where it is and the controllers are told why.
Reviewers answer with a code, and the worst code decides the next state. The document page shows the workflow's path in its own words, who owes the next move, and the response clock.
Engineers already use these codes on paper transmittal forms, so there is nothing new to learn. The difference is that the code, the comment and the name behind them are captured together and stay attached to that revision for good.
Switch on the comment sheet for a project and each document gets one Excel-style sheet covering all its revisions. Reviewers add comments, the concerned person responds, and the author marks each one resolved. Open rows show at a glance what still needs a follow-up before the next revision goes out.
Many clients still want a comment sheet in their own format at the end of each review cycle. The sheet keeps that habit and drops the copying. Comments are typed once, responses sit right beside them, and the export is ready whenever the client asks for it.
A transmittal freezes what was sent and to whom. Recipients acknowledge it, and anything unacknowledged is visible. Distribution lists send approved documents to the right organisations and roles.
A transmittal answers the three questions that come up in every progress meeting: what did we send, who got it, and did they confirm. With the record kept here, the answer takes seconds instead of a hunt through sent mail.
The dashboard counts each document by its current revision. Performance metrics show cycle time per gate, rework and the gate that holds things up, so bottlenecks show before they become claims.
Project managers bring these numbers to the weekly meeting. If one consultant takes twice as long to return drawings, or one discipline keeps getting code 3, it shows up here first, while there is still time to act on it.
Every action carries who, what, when and under what authority. The trail cannot be edited or deleted, and a hash chain exposes any attempt. Platform support actions are attributed too.
Auditors and claims consultants usually ask for the same thing: show me who did this, and when. The trail answers that directly, and because each entry is chained to the one before it, a missing or altered entry would stand out.
Everything that shapes a project lives on a screen the project administrator can reach: who belongs to it, what each role may do, how documents are numbered and which route a drawing takes for review.
Changes take effect at once and land in the audit trail like any other action, so there is never a question about who altered a rule or when. When a project ends, the same administrator takes the backups, runs the close-out and decides how long the records are kept.
A project administrator raises a support request from the portal itself. They pick what they need from sixteen request types, and the form asks only for the details that kind of request needs. Each request gets a ticket number and a reply due time that follows its priority.
When a problem is easier to show than to describe, our support desk can view the project as the person who reported it. That is remote support without a screen share. The session has a time limit, the person is told who is looking and why, and every step is recorded under the helper's own name. A project administrator can do the same for their own team, but only under a grant from the platform administrators, for one project and for a set time.
Project administrators download an Excel template, fill in organisations and members, check the file and import it in one go. New people get a one-time password and set their own at first sign-in.
Bringing a new subcontractor on board used to mean a day of creating accounts by hand. With the template, their administrator fills in one sheet, the file is checked, and every person is created with the right role in a single step.
This is the full list of what people can do in the portal today, grouped the way the menu is. Nothing is left out to keep the list short.
The first screen after sign in, plus the tools in the top bar that follow you onto every page. They show what needs you today and take you anywhere in a keystroke or two.
14 featuresThe register is the project's record of every drawing and document, with its current revision, state and file. Everything else in this area works from it.
16 featuresA transmittal is the contractual record that named revisions went to named parties on a date. This area covers issuing, acknowledging and tracking them, on screen and on paper.
6 featuresFormal exchanges between organisations, numbered and held in the record. Once sent, nothing can be edited or withdrawn.
8 featuresWhere documents move. Each gate names who reviews, in what order and by when, and the portal keeps the clock and the record.
12 featuresReports are worked out from the register, the review record and the correspondence, so they match what people see on their own screens.
3 featuresSet-up and upkeep for a project administrator or document controller: who is on the project, how documents are numbered, who may see what, and how it is closed out.
18 featuresThe console for platform administrators and support staff. What each person sees depends on the tier of access they hold.
36 featuresAccess follows the project, the company and the role. A project you are not on does not appear to exist.
Companies join a project as participants, and each person holds a role inside their own company. Drawings that are still work in progress stay with the company producing them until they are shared, and every party can see what is waiting on whom.
See approved documents, receive them by distribution, and keep a defensible record of what was approved, by whom and when.
Receive submissions by transmittal, assign discipline reviewers, decide with a review code and see which party owes the next response.
Register drawings, run internal review gates, issue to the PMC, and receive the next revision automatically when a document comes back.
Own the register, issue revisions and transmittals, consolidate reviews, manage hard copies and export the record.
A clear task list, one place to record a code and comments, and delegation or alternates for leave.
Sets up the project, its workflow, numbering, calendar and members, then keeps an eye on the metrics, the backups and the close-out.
Tell us about your project, your numbering and your approvals. We will set SetuVault up for your team.