Why contracts remain pending

Sending a contract electronically does not mean that the contract has been completed. Recipients may overlook an email, need clarification, be unavailable or wait for internal approval. Where several people must sign, one outstanding action can block the entire process.

Without structured follow-up, employees have to review pending documents regularly. They then write individual messages, search for the appropriate contact or resend files. This takes time and makes communication less consistent.

Automated reminders handle the repetitive part of this work. However, a practical workflow should do more than send the same message at fixed intervals. It needs to account for document status, signing order, deadlines, ownership and delivery errors.

Statuses the system should distinguish

“Pending” is too broad a label for targeted follow-up. An e-signature system should be able to determine whether a document has been:

• created but not yet sent,
• delivered successfully,
• opened by a recipient,
• assigned to a particular person in a signing sequence,
• partially signed,
• declined,
• sent to an incorrect or unreachable address,
• expired or voided,
• fully signed and completed.

These distinctions prevent inappropriate communication. A recipient who has declined a contract should not receive another standard reminder. Resending a message to the same address will not resolve a delivery failure either; that event requires internal review.

Sequential workflows also need specific logic. If a managing director must sign before a customer, the customer should not be reminded about a task that has not yet been released to them.

Designing effective reminder rules

A reminder schedule should reflect the type of transaction. A time-limited offer may require a different approach from an employment contract, a power of attorney or a long-term framework agreement.

An illustrative rule could follow this sequence:

1. Send the signature request with a clear deadline and named contact.
2. Send an initial reminder if no action occurs after the configured period.
3. Send a further reminder shortly before the specified deadline.
4. Escalate internally if the transaction remains pending.
5. Stop all reminders once the document is signed, declined, voided or affected by a delivery error.

The relevance of each message matters more than a high sending frequency. Excessive reminders may be ignored or perceived as intrusive. Too few reminders, on the other hand, can leave transactions pending unnecessarily.

Rules should therefore be configurable by document type, team, recipient role or expiry date. International processes also need to take account of time zones, local working days and suitable language templates.

What a useful reminder should contain

Recipients need to understand what the request concerns and which action is expected. A factual reminder can include:

• the name or a short description of the transaction,
• the sending organisation,
• the specific outstanding action,
• the agreed deadline, where applicable,
• a secure link to the signing process,
• contact details for contractual or technical questions.

Confidential contract details should not appear unnecessarily in subject lines or openly readable email text. A neutral transaction name may be more appropriate than a detailed description of a termination agreement, medical document or compensation arrangement. The acceptable level of detail depends on the context and sensitivity of the data.

The access link should not expose more information than necessary. Depending on the risk associated with the transaction, additional authentication may be appropriate. A reminder must not bypass existing security controls or weaken them by offering a less protected alternative link.

Practical example: two signers in sequence

A company sends a framework agreement to a supplier. The supplier’s project manager must sign first, followed by a managing director with the required authority.

The workflow can operate as follows:

• After dispatch, only the project manager receives a signature request.
• If no action is taken, reminders follow the rule configured for that person.
• Once the project manager signs, the task is released to the managing director.
• The reminder period for the second signer starts at that point.
• If either person declines, external reminders stop and the internal contract owner is notified.
• After completion, the intended parties receive confirmation and, where configured, the signed document.

This example demonstrates why reminders should be event-driven. A general schedule based only on the original dispatch date could contact the second signer too early or too late.

Escalation instead of endless repetition

Not every pending contract can be completed by sending more email. After the configured reminder sequence, the workflow should create an internal task. The responsible employee can then determine whether the recipient has questions, the address is incorrect or the transaction should no longer proceed.

Possible escalation steps include:

• notifying the contract owner,
• creating a task in the CRM or contract management system,
• alerting the relevant sales, HR or procurement team,
• pausing the workflow until a manual review is complete,
• voiding the signature request and preparing a corrected version.

Each escalation should have a clear owner. Sending a notification to a shared inbox without assigning responsibility merely moves the bottleneck elsewhere.

GDPR: data minimisation and retention

Reminder functions process personal data such as names, email addresses, organisational roles, timestamps and interactions with signature requests. The responsible organisation therefore needs to define why this information is processed, the applicable basis for processing and how long the information is required. The appropriate GDPR basis depends on the specific circumstances and should be assessed by the organisation.

Relevant implementation measures include:

• using only the recipient data required for the workflow,
• limiting message content to necessary information,
• defining access rights for workflow and log data,
• establishing retention and deletion periods,
• reviewing service providers and data processing agreements,
• considering transfers of personal data to third countries,
• protecting logs against unauthorised access and modification.

Tracking functions also require attention. Recording whether an email or document has been opened is a separate consideration from providing the signature function itself. Data should not be retained merely because the system is technically able to collect it.

eIDAS and the signature level are separate issues

An automated reminder does not change the legal quality of an electronic signature. The choice between a simple, advanced or qualified electronic signature depends on the transaction, applicable formal requirements and the desired level of assurance and evidence.

The reminder workflow must reliably support the selected signature level. A qualified electronic signature may involve additional identification and authorisation steps, for example. The reminder should direct the recipient into that defined process rather than provide an alternative completion route that falls below the intended signature level.

A detailed audit trail does not replace an assessment of formal requirements either. It documents technical and procedural events, but it does not by itself determine whether the appropriate form has been selected for a particular contract.

Audit trails and traceability

For operations, support and subsequent review, the system should record relevant events. These may include:

• creation and dispatch of the signature request,
• recipients and the intended signing order,
• times at which reminders were sent,
• delivery failures and status changes,
• decline, expiry or voiding of a request,
• completion of the signing process.

The record should distinguish between automated events and manual actions. Corrections to recipient addresses or document versions should also be traceable. At the same time, data minimisation still applies: not every detail that can be captured needs to be stored indefinitely.

Metrics without misleading conclusions

Teams can evaluate how long transactions remain in particular statuses, where delivery failures occur and how often manual escalation is needed. These metrics can help improve templates, responsibilities and deadline settings.

However, the absence of a signature does not automatically indicate a problem with reminder logic. The contract may be unclear, the wrong contact may have been selected or an internal approval may be missing. Workflow data should therefore be interpreted together with the relevant business context.

Implementation checklist

Before activating automated reminders, organisations should clarify:

• Which statuses trigger a reminder?
• Which events stop reminders immediately?
• Do rules vary by document type or recipient role?
• Who is notified about delivery errors, declines or expired requests?
• Which information may appear in the email and subject line?
• How are time zones and absences handled?
• Which signature level and authentication method does the transaction require?
• Which events are included in the audit trail?
• How long are workflow data and logs retained?
• How can employees pause reminders or void a request?

A reliable reminder workflow combines automation with clear stopping and escalation rules. Its purpose is not to send as many messages as possible, but to move pending signature requests towards the next appropriate step in a controlled, data-conscious and traceable manner.