How to choose eOffice software: a scoring framework for large organizations

The real question when choosing eOffice software is not "which product is best" but "how do I compare five proposals when all five claim every feature". The short answer: stop comparing feature tables. Build your own scoring framework, weight it by what actually matters to your organization, and make every vendor prove itself on the same business scenario.

This article lays out criteria for choosing eOffice software across five layers, how to turn them into a score, how to run a real evaluation, and the warning signs worth catching early. The framework is vendor-neutral and works just as well for assessing the system you already run.

Why feature tables lead to bad decisions

A feature table has three built-in defects. It records existence, not quality: "role-based permissions" might mean three hard-coded roles, or a matrix across departments, document types and confidentiality levels. It is written by the seller, so every box is ticked. And it ignores the hard part of a large rollout entirely: legacy data, established clerical habits, the capacity of your operations team, and what happens in year three.

Good criteria do the opposite. Each one is phrased as a question that can be verified by a demonstration or a document, never by a promise. If you cannot think of a way to verify a criterion, it is not usable yet.

The five layers

Work through them in order: process, technical, compliance, operations, commercial. A failure at a lower layer voids every advantage above it. An elegant system that cannot issue a correctly formatted official document is unusable, no matter how open its API.

Process: does it actually do records management

This is the layer most often skipped, because everyone assumes it is obvious.

• Document formatting. Issued documents must follow the format prescribed by Decree 30/2020/ND-CP on records management: reference numbers, recipient lists, signing authority blocks, confidentiality and urgency markings. Ask each vendor to issue three different document types and print them for comparison. We covered this requirement set in more depth in our article on document management software under Decree 30.
• Registers and numbering. Automatic numbering by register, by year, by unit, with correct handling of withdrawn, superseding and classified documents. Ask directly what happens when two people hit issue at the same second.
• Multi-level approval. Routing through several levels, signing on behalf, delegation while a leader is away, return with comments, lateral transfer between units. The hardest scenario is a document returned mid-flow that must resume from a specific step rather than from the start.
• Digital signing. Personal and organizational signatures, mobile signing, batch signing, and signatures that remain verifiable years after the document is archived. The governing framework is Decree 23/2025/ND-CP on electronic signatures and trust services; the practical side is discussed in our piece on internal digital signing.
• Case files and archiving. Documents must group into case files that can be closed and submitted to the archive with metadata intact. Many systems stop at storing loose files.
• Search. By abstract, reference number, date, unit and signatory, plus full-text search inside Vietnamese attachments with diacritics.

Technical requirements for an electronic office system

Your IT function should score this layer, not procurement.

• Architecture and runtime. What the system runs on, how it is packaged, and how long it takes to rebuild from scratch on your own infrastructure. Ask about separate development, test and production environments.
• SSO and Active Directory integration. Users sign in once with existing accounts rather than acquiring another password. Check which protocols are supported, whether the organizational tree syncs from LDAP or Active Directory, and what happens when someone leaves or transfers: does the account close and are old permissions revoked.
• Role-based permissions. Permissions should attach to roles and positions in the org tree, not to named individuals. Test one case: a manager holding two concurrent posts, and what they can see.
• Open APIs. Public API documentation available to third parties, separate machine-to-machine authentication, and webhooks so other systems learn when a document changes state. Open APIs are what let you connect HR, finance or reporting later without asking the vendor each time.
• Performance and scalability. Demand numbers at your scale, not demo scale: concurrent users, annual storage growth, time to open a document with a large attachment. Ask how the system scales when the number of units doubles.
• Backup and recovery. Two numbers belong in the contract: maximum data loss and maximum downtime in an incident. More importantly, require a live recovery drill during acceptance rather than trusting a written procedure.

Compliance: where the data lives and who touched it

• Data location. Where data and backups physically sit, who administers that infrastructure, and whether the vendor can reach production data. This is an architecture question, not a policy question; the longer analysis is in our article on on-premise versus cloud for data compliance.
• Audit trails. Every read, edit, issue and download leaves a timestamped, attributed record, and that log cannot be altered by the business administrators themselves. Ask about retention and how logs are exported for an inspection.
• Personal data obligations. An eOffice holds HR files, petitions and citizen information, so it falls under the Personal Data Protection Law 91/2025/QH15 and its implementing Decree 356/2025/ND-CP. The software has to support the operational duties: identifying what personal data is being processed, answering data subject requests, deleting or anonymizing at the end of a retention period, and producing evidence for an impact assessment file. The organization-side task list is in our compliance checklist.
• The vendor's legal role. State in the contract whether the vendor is a processor acting on your instructions or purely a software supplier. The two roles carry different obligations and the distinction must be written down.

Operations: who does what after signature

• Rollout plan. Milestones, named owners on both sides, acceptance criteria per phase. A plan that says "three months" is not a plan.
• Legacy data migration. Who cleans it, who loads it, whether old registers continue their numbering, whether data from the previous system transfers at all.
• Training. Separate tracks for records staff, executives, specialists and system administrators. Ask about retraining as staff turn over, and whether documentation is handed over in an editable form.
• Support and service levels. The SLA should grade incident severity, state response and resolution times per grade, and carry remedies for breach. Support channels and hours must be explicit, not a floating claim of round-the-clock coverage.
• Upgrades. Security patch cadence, who pays for major version upgrades, and whether your custom work survives them. Nothing separates vendors more clearly than this question.

Commercial terms worth close reading

• Cost structure. Break out licence or implementation fees, customization, annual maintenance, infrastructure and your own internal staffing. Compare on a five-year total, because the model that is cheap in year one is rarely cheap in year four.
• Data ownership. State that data belongs to the organization, and state the obligation to hand it back in a readable format with a structural description at contract end.
• Rights over customizations. Who owns code written specifically for you, whether you receive that source, and whether you may hire someone else to maintain it.
• Exit terms. Transition support after termination, the cost of data export, and a commitment not to hold data as negotiating leverage. If exit terms are hard to write, your lock-in cost is already high.
• Security and liability. Breach notification duties, the scope of indemnity, and your right to security-test the system before it goes live.

Turning criteria into a score

Criteria are only useful when they produce a number a committee can argue about. Three steps are enough.

First, mark the mandatory ones. These are pass-or-eliminate: running on your own infrastructure if that is your requirement, correct document formatting, standards-compliant signing, immutable audit trails. Five to eight mandatory criteria is usually right; many more means you are describing one specific product rather than your needs.

Second, weight the rest across the five layers. An organization still standardizing its internal processes should weight process and operations heavily. An organization with a complex existing IT estate should weight the technical layer, because integration risk dominates.

Third, score on evidence rather than answers. Three grades suffice: seen working in a trial, backed by a document, merely asserted. The third should be worth zero. That single rule changes the quality of an evaluation entirely.

How to run a real vendor evaluation

• Send your own scenarios in advance. Do not sit through a canned demo. Write five to seven real situations, including the ugly ones, send them to every vendor beforehand and require them to reproduce exactly those. For example: an incoming document is digitized, routed to two units, one requests an extension, the reply is sent back by a leader for revision, then issued and archived.
• Let your own people drive. Have your records staff and specialists operate the system during the session. A salesperson always makes it look smooth.
• Trial with real data. A limited pilot in one unit, over two to four weeks, using real data with sensitive fields masked, tells you more than three months of meetings. Set exit criteria first: how many documents complete a full cycle, how many blocking defects, how many users manage without asking for help.
• Check references, but ask the right questions. Request customers of comparable size and call them directly. Do not ask whether they are satisfied. Ask how far the rollout slipped, how long the last serious incident took to resolve, and what they would do differently.
• Security-test before go-live. Put into the contract your right to assess the system and to halt acceptance if a high-severity vulnerability appears.

Warning signs in a sales pitch

• Agreeing to everything without asking anything. An experienced team asks back about scale, org structure and legacy data. Unconditional agreement means either the problem is not understood or the work is not really intended.
• Deflecting questions about data location and logging. If the answer turns into security slogans rather than an architectural description, keep pressing.
• No trial on your data. The stated reason is usually security or technical constraints, but the effect is that you sign without ever seeing the system do real work.
• A single bundled price. One number for everything makes comparison impossible and usually precedes surprises during the customization phase.
• No clear answer on upgrades. A vendor who cannot say what happens to your customizations after two upgrades has not been through a full product lifecycle.
• Unverifiable customer lists. Logos on a slide with no reference call available should be treated as absent.
• Deadline pressure on discounts. A limited-time price is a sales technique, not an input to a multi-year investment decision.

Conclusion

The point of a criteria framework is not to find a perfect product. It is to force every bidder onto the same measuring stick, and to force your own organization to state plainly what cannot be compromised. Most failed projects did not pick the wrong product; nobody wrote down the criteria before watching the demo.

Tetra eOffice is built to be customized and run on the customer's own infrastructure, so being scored against criteria like these is familiar territory for us. If you are assembling an evaluation matrix, book a consultation and we can run it against your actual business scenarios.