Use Sidecar for Document Requests and Follow-Ups

This pattern is useful when the difficult part is not making a list of required documents. The difficult part is remembering what was asked for, who owes the next response, and when someone should follow up.

You can begin with Customers, Requested Items or Documents, Waiting On, follow-up dates, and Activity History. Add contacts and Sidecar request email when useful. Expiration dates, platforms, OCR, reports, and internal tasks can remain secondary.

This is one of Sidecar’s Common Setup Patterns. It can stand alone or grow out of a customer package checklist.

When this setup makes sense

Use this pattern when work commonly sounds like:

• We asked the broker for a revised COI.
• The employee still owes a training card.
• The customer has not answered the onboarding question.
• The platform is reviewing the submission.
• Someone replied, but nobody updated the tracker.
• We know a request was sent, but not when to check again.

The goal is to keep the current workflow state and the communication history connected to the item being requested.

1. Create the customer and source item

Every request should be connected to the record that owns the current state.

Create the outside customer first. Then use:

• a requested item when the customer expects your team to provide or complete something
• a document when your team is asking for a replacement, correction, renewal, or missing file
• a task only when the request concerns a separate internal action

For most customer document chasing, a requested item or document is the correct source record.

Give the item a clear title. Updated Certificate of Insurance is more useful than Need document after three weeks and six email threads.

2. Add a contact when repeatable routing helps

A contact identifies who should receive communication. It is different from a tracked party, which identifies whose record is being managed.

For example:

• The broker is the contact receiving the COI request.
• Apex Trenching LLC is the tracked party whose COI is being requested.
• Red Mesa Utilities is the customer whose package requires the COI.

Add a contact when Sidecar should help choose or remember the recipient for future requests. Use a contact type that matches the operational role, such as customer, broker, platform, employee, internal team, or other.

You can still use this pattern before configuring outbound email. When communication happens outside Sidecar, update the source item’s waiting status, note, waiting-since date, and follow-up date manually so the current workflow remains visible.

3. Review before sending

When using Sidecar’s Request or Follow up action, review the message before sending.

Confirm:

1. The recipient is correct.
2. The subject and message identify the exact item needed.
3. The waiting party reflects who will have the next move.
4. The follow-up date is realistic.
5. The reply address and customer context make sense.

After a successful send, Sidecar records the request and applies the approved waiting and follow-up state to the source item.

A provider accepting a message is not the same as the recipient completing the work. Keep the item active until the underlying response, file, review, or decision is actually resolved.

In the public demo, request sends are simulated. Customer workspaces use the configured outbound provider.

4. Use Waiting On as the working queue

Open More > Waiting On when you need to answer:

Who has the ball?

A useful waiting record shows:

• the customer
• the source item
• the waiting party
• why the work is paused
• when waiting began
• when your team should follow up

The waiting note should explain the blocker in a way another user can continue. Waiting on broker for revised additional insured wording is useful. Emailed is history-shaped fog.

A future follow-up date usually means the item can remain waiting unless new information arrives. A due or overdue date means someone should review the item and decide whether to follow up, update the plan, or clear the waiting state.

5. Avoid duplicate requests

Do not send another initial request while an item is already waiting and the follow-up date is still in the future.

Before sending again, review:

• the current waiting state
• the latest request or follow-up history
• delivery or bounce information when available
• the existing follow-up date
• any inbound reply already waiting for review

When the follow-up is due, use the related Follow up action or update the current state deliberately. Sending a follow-up should usually move the next review date into the future while leaving the item in Waiting On.

The work is still waiting. The calendar merely stopped yelling for a while.

6. Review replies before changing workflow

Replies sent to a Sidecar reply address can enter Email Intake for review.

Review the sender, new message, attachments, and suggested relationships. Confirm or correct the customer and source item before applying workflow changes.

An attachment arriving does not prove that the requested item is accepted, that a document is current, or that the file meets a customer’s requirements. Update the source records only after the reply has been reviewed.

When a valid replacement arrives, update or create the document, connect it to the relevant requested item, and then update the requested-item and waiting states according to what is actually true.

7. Clear waiting when the ball moves

Waiting should not become a permanent memorial to an old email.

Clear or change the waiting state when:

• the requested document arrives
• the customer or platform completes its review
• your own team takes back the next action
• the item is completed or no longer applicable
• the request was sent to the wrong party and needs rerouting

Keep the requested item or document active when work remains. Clear waiting only because ownership changed or the obligation was resolved, not because someone is tired of seeing the row.

8. Use Reports and Today when volume grows

A small request workflow may be manageable from Customer Detail and Waiting On.

As volume grows:

• Use Today to see which customers have due or stale work deserving attention.
• Use Reports for overdue follow-ups, waiting by party, and missing required items.
• Use All Work when you need the broader unresolved backlog.
• Use Activity History to understand what was sent, received, or changed.

These views become valuable without requiring you to adopt expiration tracking or internal task management.

Keep external obligations and internal work separate

A requested item describes what the customer expects. A task describes an action your own team needs to perform.

Create a task when internal ownership needs to be explicit, such as Call broker after rejected endorsement. Do not create a task merely to duplicate Provide revised COI. Duplicating the same obligation across record types makes the workflow harder to reconcile.

Importing a request tracker

A spreadsheet may already contain customer names, item titles, current statuses, waiting parties, waiting notes, follow-up dates, contacts, and request-related comments.

Import review should confirm that requested-item, document, contact, and tracked-party columns are interpreted in the correct worksheet or row context. Historical free-text columns can be preserved when Sidecar does not have a safe native destination.

See Importing Data before using an existing chaser spreadsheet as setup input.

Sidecar records the workflow; people make the decision

Sidecar can show that a request was sent, a reply arrived, a document was updated, an item is waiting, or a status changed. It does not determine whether the response is legally sufficient, whether insurance wording is correct, whether a person is qualified, or whether a customer should approve the submission.

Next steps

Return to Common Setup Patterns to compare smaller workflows. Use Customer Document Package Checklist when you need to define what the customer expects, and Daily Workflow when request volume requires a repeatable review cycle.