Skip to content

REF / PROCUREMENT

What to require from an EDMS, and how we answer it

If you are putting an EDMS out to tender or comparing proposals, the hard part is knowing what to ask for. This page sets out the twelve areas a workable requirement covers, where specifications commonly go wrong, and how we respond to each requirement when we bid.

Request the requirements checklist Full capability matrix

REF / HOW WE BID

We respond to EDMS tenders across the region

A full technical and financial submission, assembled against the requirement in front of us. Where a local-content or joint-venture condition applies, we also bid as part of a consortium.

Send us your requirement

Answered line by line

Every requirement in your schedule gets one of three answers, mapped to the package that delivers it. No blanket claims of full compliance.

A view within one day

Send us an open tender and we will tell you within a business day whether we are bidding, so you are not left counting responses at closing.

REF / SPECIFICATION

The twelve areas a workable EDMS requirement covers

Copying a template is how a requirement ends up describing one vendor's product and excluding everyone else. Use this as a checklist to test your own against instead.

SPEC-01

Scope and current state

Departments and sites in scope, user counts by role, volume of existing physical records in linear metres, annual intake, and the systems already in place. Without these a bidder is pricing a guess, and the guess gets corrected after award.

SPEC-02

Functional requirements by group

Capture, classification and metadata, search, version control, workflow, records management, security, audit, signatures and access. Grouped rather than listed flat, so evaluation can be weighted by what actually matters to you.

SPEC-03

Records management and retention

The section most often missing. State whether retention schedules, record declaration, legal hold, disposition review and archival transfer are required. Without it you will be sold a file share with a search box.

SPEC-04

Technical architecture and deployment model

Cloud, on-premises or hybrid; data residency requirements; integration with existing identity; high availability and disaster recovery objectives stated as RPO and RTO rather than as adjectives.

SPEC-05

Performance and scalability

Expected repository size at year one and year five, peak concurrent users, peak capture throughput, and target retrieval times. These make bids comparable and make sizing verifiable at acceptance.

SPEC-06

Security and data protection

Authentication and MFA, role-based access, encryption in transit and at rest, data loss prevention, audit log immutability and retention, and the specific obligations under the Data Protection Act, 2019 that the system must support.

SPEC-07

Integration requirements

Each system to be integrated, named, with its version and whether it exposes an API. "Must integrate with existing systems" is not a requirement. It is a dispute waiting to happen.

SPEC-08

Digitisation and migration

Volume, condition and indexing depth for backfile conversion, and what happens to physical originals afterwards. Priced per image or per linear metre, against a sample survey rather than an estimate.

SPEC-09

Implementation methodology and timeline

Phases, deliverables, acceptance criteria per phase, and the client obligations each phase depends on. Bidders who cannot state their methodology cannot be held to it.

SPEC-10

Training, change management and handover

Numbers to be trained by role, delivery mode, documentation deliverables, and whether train-the-trainer is required. Leaving this vague is how an institution ends up with a configured system and a registry still running on paper.

SPEC-11

Support, SLA and maintenance

Warranty period, response and resolution targets by severity, support hours, escalation path, and what annual maintenance covers. Priced separately so bids can be compared on a like-for-like total cost.

SPEC-12

Evaluation criteria and weighting

Published weightings across technical capability, methodology, team experience, references and price. Stating them up front produces better bids and fewer challenges.

REF / PITFALLS

Six things that commonly go wrong

Each of these has a cost attached: a procurement that has to be re-run, an award renegotiated after signature, or a system that does not do the thing it was bought to do.

  • Copying a specification from another vendor's product sheet

    Requirements written around one product's feature names exclude every other bidder on wording rather than on substance, and are a common ground for procurement challenge.

  • Leaving records management out entirely

    You procure document storage, then discover at audit that retention, disposition and legal hold were never in scope and must be bought again.

  • Specifying licences inside the deployment price

    Bidders bundle licences at different terms, bids become incomparable, and you may buy licences you already own through your existing agreement.

  • Requiring an on-premises deployment by default

    Often written out of habit rather than policy. It removes AI capability, raises the price, and adds infrastructure the institution then has to run.

  • Asking for "unlimited users" without stating concurrency

    Unlimited named users and 4,000 concurrent users are different systems at different prices. Without the second number, sizing cannot be verified.

  • No sample survey before pricing digitisation

    Backfile conversion is usually the largest single line. Priced without a survey, it is either padded heavily or revised upward mid-contract.

REF / COMPLIANCE MATRIX

How we answer a requirements schedule

Every requirement gets one of three answers, and we do not blur them. The full matrix covers all 84 capabilities across twelve groups.

Comply

Available in the standard product at the stated package. No development, no conditions.

Comply with configuration

Delivered by configuring the standard product to your file plan, workflow or policy. Effort is inside the package.

Does not comply

Said so, with what we would propose instead. Full compliance against every line of a long schedule is rarely true, whoever is claiming it.

Requirement group Capabilities Reference
Capture and digitisation 8 CAP-01
Classification, metadata and the file plan 8 CAP-02
Search, retrieval and the central repository 9 CAP-03
Version and lifecycle control 7 CAP-04
Workflow and process automation 8 CAP-05
Records management, retention and disposal 7 CAP-06
Security and access control 8 CAP-07
Audit, reporting and analytics 6 CAP-08
Signatures and outbound correspondence 5 CAP-09
Access from anywhere 6 CAP-10
Deployment and architecture 6 CAP-11
Adoption, training and support 6 CAP-12

REF / SUBMISSION

What a Sibasi bid contains

Assembled for the tender in front of us, not a generic pack with the client name changed.

  • Requirements compliance matrix

    Every one of the 84 capabilities mapped to compliance status and the package that delivers it, in a format you can paste into your evaluation schedule.

  • Technical architecture document

    Deployment topology, integration surface, sizing basis, HA and DR design, and security architecture.

  • Implementation methodology

    Phased plan with deliverables, acceptance criteria and client dependencies stated per phase.

  • Team CVs and certifications

    Named consultants with Microsoft certifications and comparable project history.

  • Reference deployments

    Comparable institutions, with contactable referees where the client has consented.

  • Support and SLA schedule

    Severity definitions, response and resolution targets, escalation path and maintenance scope.

  • Data protection and security statement

    How the deployment supports obligations under the Data Protection Act, 2019, with the technical controls listed.

  • Priced bill of quantities

    Line-item pricing across configuration, digitisation, integration, training and support.

REF / NEXT STEP

Ask for the requirements checklist

The twelve areas above as a working document you can build your own requirement from, alongside the compliance matrix covering all 84 capabilities.

Request the checklist Talk to us first