An agent submission arrangement gives a named person limited authority to perform specified acts in a procurement portal for the bidder. Those acts may include creating a draft, entering administrative data, uploading approved files, making a permitted declaration, clicking the final submission control, downloading the receipt or withdrawing and replacing a tender. The authority must match the procurement rules, the portal account model and the bidder’s own approval policy. Permission to operate the portal does not automatically grant power to approve price, accept contract terms, sign a representation or bind the company.
Electronic submission is often treated as a last administrative click. In reality, the click may transmit representations, lock the package, trigger a legal declaration, establish the received time or make further editing impossible. A customer may ask an employee, consultant or technology-enabled service to handle the portal because that person has the submission expertise. Trouble begins when the team relies on an email saying “please submit,” shares a director’s password, or assumes an uploaded draft is a received tender. The operator cannot prove which acts were authorized, the customer cannot see exactly what was sent and the receipt may remain in a personal mailbox.
Treat portal operation as a controlled agency relationship. Read the tender-specific rules first, then separate content approval, corporate authority, portal identity and mechanical execution. Authorize named acts for one procurement, one package and one time window. Prefer a portal-supported named account or delegated role to credential sharing. Give the operator an immutable final manifest and an approval record that identifies the exact files, declarations, price and assumptions. Keep the customer in control of any representation that only it can make. Submission is complete only when the buyer’s system produces the required evidence and that evidence has been returned to the customer.
Access
Use named access without surrendering the customer’s identity
Portal access is evidence about who acted. Preserve that evidence. Use an account created for the named operator, a buyer-supported delegation function or an organization role assigned by the customer’s administrator. Confirm that the account is attached to the correct legal entity, procurement and lot. Test uploads, permissions, file limits, browser requirements and multifactor authentication while the team still has time to resolve a failure. The European Commission’s eSubmission guide, for example, requires EU Login and an organization registered in the Participant Register; it also distinguishes the contact person from the EU Login account used to submit. The account architecture therefore changes the handoff design.
Do not solve a weak portal design by casually sending a director’s password and one-time code to an external operator. The UK National Cyber Security Centre explains that shared work accounts remove the ability to attribute actions to a specific user and recommends delegation instead of password sharing where possible. If the portal offers no supported delegation, the customer’s security and legal owners should decide the controlled procedure. Options may include customer-operated login with supervised execution, a customer-managed session or another method the portal and policy allow. Record any exception, limit its duration and revoke access after the submission window.
- Confirm the account holder’s name and the bidder entity displayed in the portal.
- Use least privilege and a procurement-specific validity window.
- Test multifactor authentication from the intended device and location.
- Keep passwords and one-time codes out of email, chat and the bid record.
- Disable or remove delegated access when the authorized work ends.
Approval
Make final approval refer to what will actually cross the portal
“The bid is approved” is not an executable instruction. The approval record should identify the solicitation and lot, submitting entity, total price and currency, files by final name and version or checksum, portal form values, declarations, disclosed assumptions, contract exceptions and the intended submission window. It should also record the customer approver and the operator who received the mandate. The final manifest closes the gap between a reviewed document repository and the bytes selected in the upload dialog. If the portal converts files, generates a submission report or displays extracted totals, those outputs need a reconciliation step before final transmission.
Define stop conditions in advance. The agent stops if the portal presents an unseen certification, shows the wrong entity, rejects or renames a file, extracts a different price, changes the lot selection, reports malware, demands an unauthorized signature or reaches a screen that differs materially from the rehearsal. The agent does not interpret a new commitment under deadline pressure. A named customer decision-maker resolves it, and any resulting change re-enters the approval path. This protects both speed and authority because the difficult decision has an owner before the clock becomes the loudest voice.
| Element | Evidence | Why it belongs |
|---|---|---|
| Scope | Procurement, lot and bidder entity | Prevents wrong-event submission |
| Package | Manifest plus version or checksum | Binds approval to exact files |
| Commercial position | Price, currency and validity | Controls the offered economics |
| Representations | Exact declaration text and approver | Separates operation from authority |
| Time | Authorized window and deadline zone | Bounds the mandate |
| Exceptions | Stop triggers and escalation contact | Prevents improvisation |
Execution
The handoff ends with buyer-generated receipt evidence
Run the submission from a short, timed checklist. Reconfirm the event, entity and lot. Compare every selected file with the approved manifest. Review portal-generated previews and totals. Obtain the customer’s final go signal through the agreed channel if the mandate requires it. Then perform the authorized final action. Do not confuse saving, uploading, validating or generating a submission report with receipt. The European Commission’s eSubmission guide is explicit that nothing has been submitted until the final Submit control is used and that its Submission Receipt is the proof of compliance with the receipt deadline. Other portals use different evidence, so name the required status and artifact before execution.
Download the original receipt and any submission report, preserve the visible status and record the portal time, local time and time zone. Reconcile the procurement identifier, bidder, lot and file list to the mandate. Return the evidence immediately to the customer, store it in the controlled bid record and notify the named stakeholders. If the portal sends the receipt to the agent’s account, that mailbox is a transit point, not the archive. Close the authorization only after the customer has the evidence, any temporary access is removed and the activity log explains every material warning, retry or deviation.
- Capture buyer-generated evidence, not only screenshots made by the operator.
- Preserve the original receipt file and its delivery message where available.
- Reconcile entity, procurement, lot, time and package identifiers.
- Escalate an ambiguous status while the submission window remains open.
- Revoke temporary access and close the mandate after evidence handover.
What good looks like
Useful outcomes from authorize agent to submit tender
- The customer knows which person will perform each portal action and under whose authority.
- The agent receives only the access and decision rights needed for the named procurement.
- Final approval identifies the exact package, price, declarations and authorized submission window.
- Credentials and multifactor challenges are handled through an approved, auditable method.
- The portal operator can stop when the live screen differs from the rehearsed process.
- The customer receives buyer-generated proof of submission and a complete activity record.
Operating model
How to run the work
- 01
Read the governing submission rules
Identify the required portal, account model, signature or declaration rules, deadline, permitted operator and evidence of receipt. Do not infer authority from technical access.
- 02
Separate the authorized acts
List preparation, upload, attestation, final submission, withdrawal and replacement separately. Assign a named operator and approver to each act.
- 03
Establish identity and access
Use the portal’s named-user or delegation mechanism where available. Test access, organization association, permissions and multifactor authentication before the final day.
- 04
Approve the exact submission package
Freeze the file manifest, checksum or version, price, declarations, exceptions and timing. Record who approved them and what must cause the operator to stop.
- 05
Submit, verify and return evidence
Follow the rehearsed runbook, capture the buyer-generated receipt and visible status, reconcile both to the approved package and deliver the record to the customer.
Evaluation
Questions that change the decision
- Does the procurement permit a representative to perform the intended action?
- Which person can approve the bid and which person can operate the portal?
- Does clicking submit include a signature, certification or contractual representation?
- Can the portal create a named delegated user, or does the bidder need a controlled alternative?
- Which exact files, form values and price have been approved for transmission?
- What screen difference, warning or new declaration requires a stop and escalation?
- Who may withdraw, replace or resubmit the tender before the deadline?
- What evidence proves timely receipt under the buyer’s rules?
Failure modes
Where teams lose control
A broad instruction to submit may not establish authority for a signature or declaration.
Shared credentials can violate portal terms, weaken security and destroy individual accountability.
The operator may be associated with the wrong legal entity or supplier profile.
A final portal page may introduce a representation that was absent from the rehearsal.
Approval may refer to a folder while a later or unapproved file is uploaded from it.
A successful upload may be mistaken for final submission and buyer receipt.
The receipt may be sent only to the operator and lost outside the bidder’s records.
An unauthorized withdrawal or replacement may displace a valid tender.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- portal actions with a named operator and customer-side approver
- approved files reconciled by version or checksum
- days before deadline that identity and access were tested
- unresolved portal declarations at final approval
- submission attempts stopped by a predefined escalation trigger
- minutes between portal receipt and delivery to the customer
- receipt fields reconciled to procurement, entity and submission time
Questions
Common questions
Can an external agent click submit for a customer?
Only when the procurement and portal permit it and the customer has expressly authorized that named act. The parties must still determine who can make signatures, declarations or representations. Technical ability to click the control is not sufficient authority.
Is an email saying “please submit” enough?
It may be evidence of an instruction, but it is usually too imprecise for a controlled submission. The mandate should identify the procurement, bidder, exact package, permitted actions, approver, time window and stop conditions, and it must meet any formal rule in the tender.
Should the customer share its portal password with the agent?
Use a named account or portal delegation where available. Shared credentials weaken security and attribution and may breach policy or portal terms. If no delegation exists, the customer’s security and legal owners should approve a controlled alternative compatible with the procurement.
What proves that the tender was submitted?
The proof is the status or receipt specified by the buyer’s system and rules, not an upload bar or the operator’s statement. Preserve the original buyer-generated evidence and reconcile its procurement, entity, lot and timestamp to the approved package.
Sources
Primary references
- FAR 52.215-1, Instructions to Offerors Acquisition.gov
- Open procedures eSubmission quick guide European Commission
- Password administration for system owners UK National Cyber Security Centre
- Register an organisation and first administrator on Find a Tender UK Cabinet Office
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Ziva
Proposal software for source-grounded RFP, RFI, DDQ and questionnaire response work.
Bid, proposal, presales, security and compliance teams. Start with the workflow, constraints and evidence you already have.
