Skip to main content

GHL Document Builder - Customer E-Signature SOP

1. Purpose & Scope​

Set up a reusable customer-facing e-signature flow inside a client's GHL sub-account, using GHL's native Documents & Contracts module. The outcome: the client's end-customer signs an agreement digitally on their phone or laptop before work begins, and the signed PDF lands back in the client's Google Drive folder with an audit trail.

In scope:

  • Client-to-end-customer agreements where the client (one of our SC clients) needs a signature from their customer. Typical examples: service agreements, rental contracts, liability waivers, scope-of-work acknowledgments.
  • Setting up the GHL document template, the workflow trigger, the signed-document archive, and the opportunity-stage handoff.

Out of scope:

  • SC-internal agreements between Symphony Core and our own clients or contractors — those use the patterns in 10-people-operations/templates/contractor-agreement-template.md and nda-template.md.
  • Proposals with a price that needs customer acceptance before contract — use GHL Proposals (separate module), not GHL Documents. Proposals convert to an opportunity and can chain into a Document for the signed contract.
  • Google Docs shared-link signatures — no audit trail, no trigger hooks. Use only for throwaway internal sign-offs.

When to use this SOP:

  • A client has a paper or PDF agreement they currently ask customers to sign by hand / email-back / scan.
  • A client wants to block job scheduling until the agreement is signed.
  • A client wants a searchable archive of every signed agreement without maintaining a file cabinet.

2. Prerequisites​

  • Client's GHL sub-account exists and we have authenticated access (location ID captured in 09-clients/<client-slug>/<client-slug>-client-profile.md).
  • Client's Drive folder exists at H:\Shared drives\Client_Delivery\<client-slug>\ with a client-reference/signed-agreements/ subfolder. If missing, follow Google Drive Client Folder Setup SOP first.
  • The agreement text exists somewhere — paper, PDF, markdown. If it's a PDF, have a markdown or Google Doc transcription on hand so you can paste the sections into GHL's document editor.
  • An opportunity pipeline exists in the client's GHL sub-account with at least three stages: Quote Sent → Agreement Pending → Scheduled (or equivalent). Create stages if missing.

3. Merge-field naming convention​

Keep field names consistent across clients so the pattern replicates cleanly. Use GHL's standard contact/opportunity fields first; reach for custom fields only when the standard ones don't fit.

ConceptMerge fieldSource
Customer's full name{{contact.full_name}}Standard contact field
Customer's company{{contact.company_name}}Standard contact field
Customer's billing address{{contact.full_address}}Standard contact field
Customer's email{{contact.email}}Standard contact field
Customer's phone{{contact.phone}}Standard contact field
Job site address{{custom_values.job_site_address}}Custom field (create per sub-account)
Scheduled service date{{custom_values.service_date}}Custom field
Quoted amount{{opportunity.monetary_value}}Standard opportunity field
Service description{{custom_values.service_description}}Custom field
Client's business name{{location.name}}Sub-account name — auto-populated
Client's authorized rep name{{user.name}}The GHL user sending the document

Create client-specific custom fields at the sub-account level, not the agency level. This keeps the pattern portable — the next client gets the same field names in their own sub-account.

4. Steps - Building the document template​

  1. In the client's GHL sub-account, go to Payments → Documents & Contracts → Templates → + New Template.
  2. Name the template in the form <Client Business Name> - <Document Purpose> (e.g., <Business> - Service Agreement, <Business> - Rental Contract). Keep it recognizable in the customer-facing email subject line.
  3. Paste the agreement body section by section. Use GHL's editor headings (H1 / H2) — the rendered PDF uses them for the table of contents.
  4. Insert merge fields from Section 3 wherever the agreement currently has blanks ("Customer Name: ____"). Double-click the blank and replace with the field.
  5. Add a name + title block for each signing party (customer; plus a countersignature block for the client if needed). Do not include explicit Signature: ___ or Date: ___ placeholder lines — GHL Documents & Contracts captures the signature image and timestamp electronically and renders them on the executed PDF, so duplicating them in the body is redundant and looks like a wet-ink template that wasn't adapted for e-sign.
  6. Set the template's Sender to the client's authorized rep (default signer from the client side).
  7. Save and preview: open the template as preview, confirm the merge fields render with placeholder text and the signature blocks are in the right order.

5. Steps - Building the workflow trigger​

The document send should fire automatically when the customer is ready to sign, not manually.

  1. In the client's sub-account, go to Automation → Workflows → + Create Workflow → Start from scratch.
  2. Name the workflow <Document Purpose> - Send for Signature.
  3. Trigger: Opportunity → Opportunity Stage Changed → Agreement Pending. (If the client's pipeline uses different stage names, match theirs.)
  4. Action 1 - Send Document:
    • Template: the one built in Section 4.
    • Recipient: {{contact.email}}.
    • Expiration: 7 days.
  5. Action 2 - Wait until Document Signed:
    • Event: Document signed by recipient.
    • Timeout: 48 hours.
  6. On signed:
    • Action: Update Opportunity Stage → Scheduled.
    • Action: Send internal notification to the client's authorized rep (email or in-app).
  7. On timeout (not signed in 48h):
    • Action: Send reminder email to {{contact.email}}.
    • Action: Notify client's authorized rep.
  8. Publish the workflow. Test before going live (Section 7).

6. Steps - Archiving the signed PDF to Drive​

GHL stores the signed PDF in the Documents module, but for audit and cross-tool search the PDF should also land in the client's Drive client-reference/signed-agreements/ folder.

Two options:

Option A (manual, 2 min per signed doc): After each signed document, download from GHL → drop in H:\Shared drives\Client_Delivery\<client-slug>\client-reference\signed-agreements\. Name the file YYYY-MM-DD-<customer-last-name>-<document-purpose>.pdf. Use this for clients with fewer than ~5 signings/month.

Option B (automated, via Symphony Flow): Add a step to symphony-flow/config/workflows/client_document_populate.yaml that listens for the GHL DocumentSigned webhook, downloads the PDF via the GHL API, and uploads to the client's Drive client-reference/signed-agreements/ folder. Requires the webhook subscription to be enabled in the sub-account. Use this for clients with higher volume.

Start with Option A on every new rollout. Move to Option B once the client is signing more than a handful per month.

7. Verification​

Before handing the flow to the client, run one full end-to-end test using a throwaway contact in their sub-account:

  1. Create a test contact in GHL with your own email (or a test alias).
  2. Create a test opportunity on the target pipeline with a non-zero monetary value.
  3. Move the opportunity to the trigger stage (Agreement Pending).
  4. Confirm within ~1 minute that the test email arrives in your inbox with a signing link.
  5. Open the document, verify every merge field is populated (no {{...}} literals), and that the signature block works on mobile. Sign it.
  6. Confirm the opportunity auto-advanced to Scheduled.
  7. Confirm the client's authorized rep got the "signed" notification.
  8. Confirm the signed PDF is downloadable from the GHL Documents module.
  9. Archive the test: delete the test contact and opportunity, and delete the signed PDF from the Documents module if the client wants a clean audit trail.

Document the test run (one-line note) on the client's implementation checklist before handoff.

8. Rollout handoff​

  • Walk the client through a live signing once, using a test customer contact, so they see what their customer will see.
  • Show them where to manually re-send the document if a customer loses the email.
  • Show them where the signed PDFs live (Documents module + Drive folder if Option B is wired up).
  • Add a bullet to the client's training agenda: "Triggering the agreement — move the opportunity to Agreement Pending."

9. Reference​

Appendix A - When to reach beyond GHL Documents​

GHL's native Documents module is the default. Reach for an external tool only if one of these applies:

  • Notarization required. GHL doesn't support remote online notarization. Use a notary-capable platform (Notarize.com, DocuSign Notary) and attach the resulting PDF back to the GHL opportunity.
  • Sequential multi-party signing across parties who are not in the GHL contact list. GHL handles this but the UX is rough past two signers. DocuSign or SignNow handle complex routing better.
  • Legal team mandate for a specific platform. Some regulated-industry clients (healthcare, legal) are required to use a vendor on their compliance shortlist.

In every other case, GHL Documents is both sufficient and the lowest-friction choice since it's already in the sub-account we manage.