Prospector

Before Prospector, building a proposal meant opening a template, hunting for the client's logo, writing a custom About section from scratch, manually calculating the 30/30/40 payment breakdown, and hoping nothing was out of date by the time it landed in the prospect's inbox. Every rep had a slightly different version of the template. Quality was inconsistent. Time was wasted on logistics instead of strategy.

The problem wasn't effort — it was tooling. We had the efelle brand story, the verticals, the pricing structure, and the process. We just didn't have a fast way to assemble it around a specific prospect.

Prospector solves that. You enter a client URL, confirm a few settings, and the tool scrapes their site, populates all the client-specific fields, selects the right vertical copy, applies your pricing, and outputs a complete, branded, print-ready proposal in minutes. Every proposal looks like it was built by hand — because structurally it was, just without the manual assembly.

The tool also handles the two proposal types the sales team uses: a full New Website build, and a Work Order + RGS engagement for clients with existing sites who need targeted improvements plus ongoing marketing support.

Prospector is a browser-based internal tool that runs on efelle's infrastructure. It calls the Anthropic AI API to process client website data and populate proposal fields, and it connects directly to efelle's branded proposal template system. There's no login required — just open it, work through the intake, and download your file.

The tool has four core capabilities:

How to decide which type to use

If the prospect's site is fundamentally broken, dated, or needs a complete rebuild — use New Website. If their site is working but underperforming, or they want specific improvements without a full rebuild — use Work Order + RGS. If their site is genuinely fine and they just need more leads — use RGS Only.

When you pick RGS Only in Step 1, the pricing row collapses to a single field (RGS Monthly, defaults to $2,800) and the RGS Mode toggle disappears — there's no website project for the marketing program to be "optional" against. The generated proposal leads with the monthly program: an RGS-focused Scope of Work, a monthly-price offer section, a payment breakdown showing the three-month minimum and month-to-month terms, RGS onboarding process steps (campaigns live in 2–3 weeks), and agreement copy written for a marketing-only engagement. There's no new-website talk anywhere — no design or development language — but the program copy does include ongoing website content updates (new pages, refreshed content, on-page SEO) since that's part of RGS. Website-build sections — the portfolio, the feature cards and site-architecture diagram, and the 3-month build calendar — are dropped automatically. In the portfolio's place, the proposal includes two pages of real digital marketing results (two case-study graphics per page — manage the list under Settings → RGS Case Studies: add, remove, reorder, no code change needed), and the process page shows a 5-phase program launch timeline. Client logos with a lot of white in them automatically get a dark backdrop so they stay visible on the white page.

The WO + RGS proposal type assumes RGS is included, not optional — the ongoing marketing component is what makes a targeted work order worthwhile for both parties. Don't use the WO type without including RGS.

A fourth option: uploading your own proposal

Some deals do not fit any template — a service program, a proof of concept, a one-off scope you wrote yourself. On the setup screen, under Document, switch from Built from template to Custom upload and choose your HTML file. Prospector does not rewrite it. It adds the efelle Project Agreement page to the end of it, and from that point it behaves like any other proposal: a link you can email, a signature the client clicks, a signed PDF, the HubSpot deal, and the QuickBooks invoice batch.

The rest of the setup screen still matters. The client URL builds the company profile exactly as it always has, and the industry, pricing, hosting and RGS you enter build the agreement page — the signature block, the options the client checks, the program summary and the efelle footer. They are not decoration: what the client checks when they sign is what gets invoiced, the same as on a built proposal. Portfolio graphics and market type disappear while Custom upload is on, because they only steer template copy your document does not use.

Change a price later (Edit → Pricing → Apply, or step back and press Wrap the custom proposal again) and the agreement page is replaced rather than duplicated — your document, and any edits you made on the page, stay as they are. The proposal number and the hosted link stay the same too. Applying the same numbers is a quick way to refresh the agreement wording on an older upload.

Every vertical controls a specific set of copy fields in the proposal:

RGS is a monthly marketing engagement — SEO, content, paid, and performance management — designed to generate leads and grow the client's digital presence after the website launches. Every proposal includes RGS in some form. The question is whether it's positioned as an upsell or as part of the core offering.

How to decide

Default to Optional for most New Website proposals unless the conversation has already included a strong discussion about marketing and growth. When a prospect says "we really need to show up on Google" or "our current site gets no traffic," that's a signal to use Included — they've already told you growth is the goal.

For Work Order + RGS proposals, always use Included. The work order and the marketing program are one engagement — separating them undercuts the positioning.

RGS runs at $2,500/month by default with a three-month minimum term, then continues month-to-month with 30 days' notice to cancel. The pricing is set in Step 4 and can be overridden if your engagement calls for a different rate.

Default pricing

At Step 4, Prospector shows the standard defaults and asks you to confirm or override:

The 50/50 interest-free payment structure

All New Website proposals use a two-payment structure calculated automatically from the website project price. The balance is split evenly — half up front, half financed interest-free over 24 months:

All payment amounts display as whole dollars — no cents. The monthly balance amount is always rounded down to the nearest dollar. The tool handles all of this math automatically; you never need to calculate it manually.

For Work Order + RGS proposals, the payment structure is different: the work order is billed in full on a single invoice with Net 30 terms — no deposit and no milestone (this matches the Command Center's Single Invoice structure). The agreement page, the payment terms card, the Slack and email summaries and the invoicing handoff all say so automatically. Before September 24, 2026, work orders read 50% deposit / 50% at the 45-day milestone; a work order built before then keeps that wording until it is rebuilt (Edit → Pricing → Apply).

What the output file contains

The generated .htm file is a complete, standalone document. Everything is self-contained — no external dependencies that could break. It includes:

Three ways to deliver a proposal

1. Publish Link (recommended). Click 🔗 Publish Link after generating. The proposal is hosted at a private, unguessable URL (prospector.efelle.com/p/…) you can paste straight into an email. You get open tracking — the app shows how many times the link was opened and when it was last viewed (your own opens count too) — and if you filled in the Contact Email field, opens and the acceptance also log automatically as notes on that contact in HubSpot. The prospect gets a click-to-sign bar: they type their name, confirm they're authorized, and accept on the spot. On proposals with both a website component and an RGS price, they also check which program(s) they're authorizing in the Select Your Options box by the signature — and the RGS add-on checkboxes are live too — checking one updates the listed RGS price in place everywhere it appears, plus the sticky total bar at the top of the page. Add-ons are extras on the RGS program: if the client unchecks RGS, any checked add-ons gray out, drop out of the monthly total (the sticky bar notes "add-ons apply with the RGS program"), and are left out of the signed record — so a website-only signature never carries a stray add-on charge. The full selection and monthly total are recorded with the acceptance and locked afterward. The acceptance is recorded and shows in the app — and on the proposal itself, their name renders in script on the signature line with a verification line underneath (timestamp in Pacific Time, IP address, and reference ID), so the accepted page prints as a signed record. After editing a proposal, click Publish Link again — the same URL updates in place, and views/acceptance are preserved. Every proposal owns its own link: building a second proposal for the same company mints a fresh URL instead of overwriting the first, and reopening a proposal from the Library brings its published-link panel back. Open proposals also get their own app URL (/proposal/…), so refreshing or bookmarking returns you to that exact proposal. Proposals expire on their valid-through date — the hosted page blocks signing and shows an "expired" notice; the clock button in the publish panel extends the date by 14 days. The Library's Status column tracks the pipeline (Published → Sent → opened → ✓ Signed) with an orange dot for new activity since your last visit. You can also pre-select add-ons right in the builder preview — the checkboxes are live with real-time prices, and the selection carries into the published link and PDFs.

What happens when they sign. The moment a client accepts, the signed deal flows automatically into the Command Center: the company, signer, contact email, service address, and the exact price, payment structure, hosting and RGS programs they selected are published to the shared client record. Whoever runs billing then opens A/R › Invoices › Import a signed proposal in the Command Center and one click prefills the whole invoicing form exactly as signed — no retyping, no transcription errors. Nothing about this changes the signing experience, and if the Command Center is ever unreachable the acceptance still records normally.

1b. ✉️ Email. The Email button (last on the toolbar) publishes/refreshes the link and opens a ready-to-send intro email in your mail client — subject, proposal link, and step-by-step signing instructions pre-written, and fully editable before you hit send.

Texting or pasting the link. When a proposal link is texted or dropped into iMessage, Slack, or LinkedIn, the preview card shows the Share preview image set under Settings → Share preview image — upload a wide graphic (ideally 1200×630) or paste an image URL, click Save, and every proposal link uses it from the next share on, no republish needed. Without one, an efelle-branded default card is used. Messaging apps cache previews, so a link that was already sent may keep the picture it first showed. Those preview fetches no longer count as opens or log a HubSpot "opened" note — only real visits do.

2. Download PDF (under the Download ▾ menu). One click, rendered on the server — identical pagination every time, no print dialog. This is the file to attach when a prospect wants a document. Add Logo, Edit with AI, Edit Text on Page, and Update Address / Details live under the Edit ▾ menu. Edit Text on Page makes the preview directly editable — click any text in the proposal, type your changes, and hit Save; edited prices are re-synced automatically and the change lands on the live link and the Library copy. Update Portfolio and Edit Pricing / Discount are covered just below.

Client details are locked once a proposal goes out

The rule. The client facts you type or correct on the client form (company, contact, email, phone, street, city, state, zip, website) are the truth for that proposal. The first time it is published or emailed they are locked on the saved proposal: from then on nothing in the app can change them by accident. Research, the WAR loader and the "load client from another report" picker are blocked while locked, Build re-applies the verified values before it reads the form, and any save or republish that would change a locked field is refused with a message naming the field.

Changing them on purpose. A banner above the client fields shows the lock (who, when). Click Unlock to edit, give a reason, make the change, then Build or Publish; the details re-lock with the change logged and the previous values kept. If you have verified the details before the proposal goes out, Verify & lock now locks them early.

Research never overwrites. Research fills empty fields only with values read from the client's website. Anything that differs from what is already in the form, and anything found elsewhere online (a lookup address or phone), appears in a review list under the status line with a Use button per field and a warning that it may belong to a different business with the same name. Nothing changes until you click Use.

What happens when a client signs (and when a proposal goes out)

You are told the moment it happens. When a client clicks Accept & Sign, Prospector does five things on its own: posts to Slack #team-sales; emails sales@efelle.com and billing@efelle.com with the signed PDF attached; sends the client a confirmation email with the same PDF (to the Contact Email addresses on the proposal); saves a copy of the PDF to the Signed Client Project Agreements folder in Google Drive; and sets the HubSpot deal to Closed Won with the signed amount and the signature date as the close date, and moves the contact and their company to Lifecycle "Customer" with Lead status "Client", and attaches the signed agreement PDF to the deal, company and contact in HubSpot (the proposal PDF is attached the same way when the proposal first goes out). The deal is found through the contact email, so fill in Contact Email on the client form and make sure the contact is Qualified in HubSpot (that is what creates the deal) before you publish.

Proposals going out are announced too. The first time a proposal is published (Publish Link, or the Email button, which publishes first), Slack #team-sales and sales@efelle.com get "Proposal created for {contact} @ {company} for $X on {date}" with the link, and the HubSpot deal gets the amount, the valid-through date as its close date, a Proposal Sent Date, the proposal link, and moves to Proposal Sent if it was at an earlier stage. Republishing after edits does not re-announce; it only refreshes the deal amount if the price changed. Clicking Email later stamps a fresh sent date.

Deal amount. HubSpot wants one number, so the deal carries first-year value: the one-time price plus twelve months of the monthly program. Before signature that is what was offered (programs, not optional add-ons); after signature it is what was selected. An $8,865 website with $85/m hosting becomes $9,885.

Download PDF. A signed proposal's green banner carries a Download PDF button, for the client and for you, and the Published panel in the app has the same download (the arrow icon). The file is named {company-name}-signed-agreement-MMDDYYYY.pdf everywhere it appears: the download, the email attachments, and the Drive copy.

The ALERT! panel. Every signed agreement shows at the top of the home screen the moment you open the app: company, who signed and when, what they selected and for how much, and links to the hosted proposal, the signed PDF, the proposal in the app, the HubSpot deal and the Drive copy, plus a row of chips showing whether each notification went out. Click Acknowledge once the team has picked the project up; it moves to a collapsed "acknowledged" list that is shared by everyone (Un-acknowledge brings it back).

RGS reads as a suggestion, not a given. Because a client can uncheck RGS in the Select Your Options block, proposals built from v4.39 on say "We're also suggesting our Revenue Growth Services (RGS)", head the program cards with "If the RGS program is selected, the following items are included:", and the RGS intro, the options box and the agreement paragraph on the last page each say in one line that RGS is part of the agreement only when its box is checked. Proposals already published keep the wording they were built with.

Correcting a signed document (admin only). A signed proposal is locked, but when a client agrees to a correction (wrong company details, for example), an admin can open the corrected version in the builder and click the pencil button in the Published panel. The acceptance stays exactly as recorded, the previous version is kept on the server, the PDF is re-rendered, a corrected copy goes to Drive, and the document's verification line says it was corrected at the client's request. You are asked for a reason, which stays on the record.

Checking that it went out, and sending it again. The Published panel shows a chip per channel: green check when it worked, orange warning when it did not, with the reason on hover. The bell button re-runs the Slack post, the sales/billing email (PDF attached), and the HubSpot Closed Won update for a signed proposal. Use it for a proposal that signed before this existed, or after fixing a channel that failed. The client's confirmation email is never re-sent from there; forward it if they need another copy. In Settings, the Proposal notifications band shows what is connected and Send a test posts a test to Slack, emails sales@, and checks HubSpot and Drive, so you can confirm the setup without signing anything.

Portfolio graphics — choosing them yourself

Every proposal shows portfolio graphics matched to the vertical you picked in Step 1. Roofing proposals get the roofing shots, landscaping gets landscaping, and so on. That still happens automatically and you do not have to do anything.

When you want different graphics, the proposal setup screen has a Portfolio graphics section under the vertical grid. Click Choose graphics and you see every image available — everything loaded under Settings → Portfolios (whatever industry it is tagged with) plus the built-in library for all the verticals. Click up to four in the order you want them to appear; the numbers on the cards show that order. The graphics your vertical would have picked on its own are outlined with a dashed border and marked auto, so you can see what you are replacing. Underneath, an In this order on the page strip lists what you have pinned, numbered, with arrows to reorder and an × to drop one — so the order is never a guess. Click Back to automatic to undo the whole thing. The magnifier in the corner of a card opens that image full size.

Changing graphics on a proposal you already built — including one you have already published — go to Edit ▾ → Update portfolio. The preview itself becomes the picker, and every graphic in the proposal gets an orange tag showing its position, with three buttons on it: ↑ and ↓ to move it up or down the page, and × to take it out.

To swap one out, click the graphic in the proposal (its tag changes to Replacing), then click its replacement below. You do not have to select anything first, though: with nothing selected, clicking a thumbnail adds it to the end, and clicking a thumbnail that is already in the proposal takes it back out. Every change saves straight to the published link and the Library copy — nothing else in the document is touched, and you never have to rebuild the proposal.

Graphics that stop loading. If a portfolio image is moved or deleted on the web server, it used to show up in the client’s proposal as an empty box with a caption in it. Now any graphic that fails to load is dropped from the client’s copy automatically, and you get an orange banner above the preview saying how many went, with an Update portfolio button to put replacements in.

How they print. One or two portfolio graphics print on a single page. Three or four are split two per page — the third starts a fresh page — so each one stays big enough to read the before-and-after detail. This applies to Download PDF and to Print / save as PDF.

What the Offer section looks like

The Offer page leads with a dark pricing card: the price on the left, the pitch for the build on the right. Below it, a Cost & payment breakdown panel splits into three cards, answering the three things a client asks in order: what the work costs, when each piece is due, and what recurs every month.

One thing to know about how a discount reads. The large number in the dark card is the list price with a line through it, with a “you save” pill underneath. The figure the client actually pays is the big number in the breakdown, under Your project price. If a particular deal would land better leading with the discounted number instead, that is a quick change to make.

Work orders and RGS-only proposals use the same design with wording to match, and toggling optional services later in the proposal still updates the RGS figure in the breakdown.

Discounting a project or work order

Next to the price on the setup screen there is a Project discount field (it reads WO discount on a Website Updates work order). Enter the dollar amount you are taking off — leave it at $0 and nothing about the proposal changes.

With a discount entered, The Offer shows the full list price struck through next to what the client actually pays, with the discount named underneath it in orange. The payment breakdown spells it out in three lines: the work at list price, the discount, and the adjusted total. Everything downstream recalculates off the discounted figure — the 50% deposit, the balance spread over 24 months, and the totals in the agreement.

Adding or changing a discount later — on a proposal that is already built, go to Edit ▾ → Edit pricing / discount. The price, discount, hosting, RGS and (on a work order) hours are all there; change what you need and click Apply. The proposal rebuilds and the new figures go out to the published link and the Library copy. One thing to know: Apply rebuilds the document from the client details, so if you have hand-edited the text with Edit Text on Page or the AI chat, those edits are replaced. Do your pricing first, then your text edits.

3. Manual print (fallback). The original Chrome print flow, documented below — only needed if the server PDF is unavailable:

On the intake

On pricing and positioning

On output and delivery

Replacing Proposify with a native signature block

The current workflow requires exporting to PDF and either printing for wet signature or routing through Proposify or DocuSign as a separate step. The next version of Prospector will embed a digital signature block directly into the proposal output — no third-party tool required.

The signature block will be generated as part of the HTML output and include: client name and company, signature field (drawn or typed), date field, and an "I agree to the terms above" checkbox. When the client completes the signature in-browser, the signed version will be captured and can be sent back as a finalized PDF. This removes Proposify from the workflow entirely for standard engagements — reducing both cost and friction.

HubSpot integration

Most of this is now live (v4.38, see "What happens when a client signs" in section 9): publishing stamps the deal with the amount, close date, sent date and link and moves it to Proposal Sent; signing sets it to Closed Won; opens and acceptance log as notes on the contact. What remains:

Future state: Slack-native proposal generation

The long-term vision for Prospector is that generating a proposal should be as fast as sending a Slack message. The goal is a slash command that handles the entire workflow in one line:

The command format is /proposal [clienturl] @ [project price] / [RGS price] / [hosting price]. Prospector handles everything else automatically: scrapes the client site, detects the industry vertical, applies the right copy, calculates the payment schedule, and returns a download link to the finalized PDF — all within the Slack thread, without leaving the app.

The same command will optionally trigger HubSpot deal creation and attach the proposal to the correct contact record, so the entire sales motion from "I want to send a proposal" to "deal logged in CRM" happens in one command.

Other items on the roadmap

Dashboard (home)

The hero has the quick actions: New proposal, New WAR report, Find prospects, and a Toolkit menu with the remaining programs. To its right, this month's scoreboard: proposals sent, the close rate over the last 90 days, and the one-time revenue signed this month. Below that, the pipeline band counts what is in motion: prospected (companies with any document this month), audited (WAR reports and competitor analyses this month), pitched (proposals out for signature) and signed (agreements waiting for a kickoff).

The kickoff queue lists every signed agreement: value, who signed and when, the program, and a sync line showing which of Slack, the team email, the client email, HubSpot and Drive went through, with anything missing called out. Open proposal opens the hosted link; More holds the signed PDF, the HubSpot deal, the Drive copy, Open in app and, last, Delete from dashboard; Build invoice (orange) opens the Command Center's Import a Proposal page with that proposal ready to pull into an invoice; once the deal is invoiced the same button reads View invoices and opens the deal's invoice summary in the Command Center. Delete from dashboard is for tests and finished deals: the row leaves the queue, the pipeline and the scoreboard, while the hosted link, the signed PDF and the Library entry stay. The sync line also carries Invoiced: it turns green on its own when the Command Center creates the QuickBooks invoices for the deal (with the invoice number), or use Mark as invoiced under More. Archive to Invoiced proposals then moves the deal out of the queue into the Invoiced proposals list under the Open proposals table, where it keeps its links and can be restored. Invoicing also shows up in Recent activity. Once invoiced, the sync line adds Deposit sent and Deposit paid, which the Command Center ticks on its own (sent when it emails the deposit invoice, paid when QuickBooks shows a zero balance), and the sales Slack channel gets a one-line post at invoicing and again at deposit paid. More also has Start onboarding, which opens the Client Onboarding tool with that deal picked. Anything listed as missing on the sync line explains itself: hover for the reason, click to retry that one channel. A Thank-you note check covers the personal follow-up email the client gets after signing (reply-to is the rep, sales@ gets a copy). In manual mode (the default) it waits on the card: More → Preview & send thank-you note opens a window with To, From, Reply-to, BCC and the rendered email, and nothing goes out until you click Send to client. In automatic mode it is sent on its own after the delay set in Settings; the mode in force when the client signed is the one that deal follows. Its wording and timing live in Settings → Thank-you note: edit the subject and body with merge fields ({firstName}, {company}, {repName}, {agreementLink} and more), set the delay in minutes, Reset to default, or Email me a test rendered from the newest signed deal. Settings → HubSpot email logging holds the Log to CRM BCC address once; every client-facing email the app sends is copied there so HubSpot files it on the contact and company. Settings also shows the nightly backup (the whole data volume to a Prospector backups folder in Drive, 14 kept) with a Back up now button. In the Library, Actions → Version history lists every earlier copy of a document with what replaced it; Preview shows one, Restore brings it back (the current copy is kept, and an unsigned hosted link follows). A deploy no longer signs you out; when a newer build is live a Refresh bar appears at the bottom of the page. Email the proposal in the builder now sends from the app: the window shows the saved wording for that deal with To, Cc, Subject and the message editable, plus a live preview; click Send, or Open in Outlook instead. Opens of the email show in the publish panel next to the link views. On a kickoff card, Nudge for deposit appears once the deposit invoice is a week old and unpaid and opens the same window with the reminder. Both wordings live in Settings (Proposal email, Deposit reminder), and Settings → Proposal notifications → Show me what goes out renders every automated message from your newest signed deal. Timeline (More on a kickoff card, the clock icon in the publish panel, or Library → Actions) lists everything that happened to a deal in one place, newest first, including every edit. Under the card, "Deposit unpaid N days" appears once the deposit invoice has been out a week, and the scoreboard shows close rate by rep for the last 90 days. Slack gets exactly two posts per deal: signed, then "Invoices sent".

Client Onboarding (Tools, stage 04). Pick a signed deal, set the kickoff call date, the target launch if known, the project manager and the rep, add any team notes, and click Generate kickoff plan. The plan is written from the signed proposal and its builder data: deal at a glance, scope and out-of-scope, a phase timeline with dates counted from the kickoff call, the staging review gates, efelle and client responsibilities, the assets to collect, first-week action items and risks (the first risk is the deposit whenever the deal is not invoiced or paid). It saves to the Library as a Kickoff plan and downloads as HTML or PDF.

Site Blueprint (Tools, stage 05). Pick the signed deal, set a page-count target and CMS if they differ from the proposal, add notes, and click Generate Site Blueprint. It reads the signed proposal and the kickoff plan (run Client Onboarding first for the best result) and drafts the sitemap, navigation, a page-by-page plan with slugs, keyphrases, sections and conversion actions, the templates to design, a content binder skeleton with placeholders for facts the client must supply, assets and integrations per page, and open questions. It saves to the Library as a Site blueprint.

Open proposals shows every hosted proposal that is not signed: sent date, value (project total plus hosting), and status (viewed n times, not opened, or stale // n days in orange once it passes the threshold). A stale row gets a Nudge button: it opens a follow-up email in your mail client with the proposal link, and the nudge is recorded. The threshold is 14 days; click the number in the line under the table to change it for the whole team. Recent activity lists sends, views, signatures and reports as they happen.

Tools

Every program across the seven deal stages, in three views: Table, Cards or Workflow (stages left to right, parallel tools stacked). The toggle remembers your last choice. Programs that are not built yet say so when clicked.

Library

Search by company (it also matches the meta line, so "roofing" or "by Doug" works), narrow by Type, Created by and Status (Draft, Sent, Viewed, Signed); the filters combine and the counter shows "n of N shown" with a clear link. The Created column header flips between newest and oldest. The filters and the column header stay put under the nav as you scroll. Each row's Actions menu has Open, Download PDF (HTML for reports), Duplicate (a fresh draft with no link or lock), Copy share link and Delete.

Settings

Two connection cards at the top (Railway persistence, proposal notifications with Send a test), then three collapsible sections: Portfolios (thumbnail, client name, image URL, vertical, reorder and remove), RGS case studies (same, with a name instead of a vertical) and the Share preview image. API keys and the API model string sit at the bottom of the page.

Hosting

GitHub efellefred/efelle-prospector, branch main; a push deploys to Railway (project lucid-victory, service efelle-prospector, domain prospector.efelle.com). A deploy takes 2–4 minutes; while the container swaps the site answers 502 and the login form shows its generic "invalid" message. Every deploy signs everyone out (sessions live in memory). Proposals, hosted links, cached PDFs, backups and hosted logos live on the Railway volume efelle-prospector-volume at /app/data.

Railway variables (service → Variables): TEAM_PASSWORD (login), HUBSPOT_TOKEN, SLACK_BOT_TOKEN (+ optional SLACK_SALES_CHANNEL, default #team-sales), RESEND_API_KEY + PROPOSAL_EMAIL_FROM (+ optional SALES_NOTIFY_EMAIL, SIGNED_NOTIFY_EMAILS), GOOGLE_SERVICE_ACCOUNT_JSON + GDRIVE_IMPERSONATE=billing@efelle.com (+ optional GDRIVE_SIGNED_FOLDER_ID), COMMAND_CENTER_RECORD_TOKEN. Settings → Send a test tells you which of these are missing or broken.

HubSpot

Portal 2032370. Auth is the Service Key "efelle report generator" (Development → Keys → Service Keys), shared with the Command Center report tool. It must carry: contacts read/write, deals read/write, deal schemas read/write, companies read/write, and files. Editing scopes does not change the token. Deals are found through the contact email (newest open deal in the Sales Pipeline); HubSpot creates deals when a contact is set to Qualified, Prospector never does. Stages used: Proposal Sent, Closed Won; never moved backwards. Custom deal properties Proposal Sent Date and Proposal Link are created automatically. Deal amount = the net one-time project total after discount, pre-tax, no hosting. On signature the contact and company become Lifecycle Customer / Lead status Client and the signed PDF is attached to the deal, company and contact; the proposal PDF is attached when it first goes out.

Slack

Workspace efelle creative, app eProjectUpdate (also the Command Center's bot). Bot scopes chat:write, channels:join, channels:read. Posts go to #team-sales; the bot joins a public channel by itself.

Email (Resend)

Account efelle, domain efelle.com verified, API key "Prospector", sender proposals@efelle.com. Signed notices go to sales@ and billing@ with the PDF attached; the client gets a confirmation with the same PDF.

Google Drive

Folder Signed Client Project Agreements (owned by billing@efelle.com, in billing's My Drive). Google Cloud project efelle-internal with the Drive API enabled and the service account efelle-report-generator@efelle-internal.iam.gserviceaccount.com; its key is the Railway variable above. Because the folder is a My Drive folder, uploads act as billing@ through domain-wide delegation (Google Admin → Security → API controls → entry "efelle Command Center", client id 116935313050521627175, scope auth/drive). Files are named {company-name}-signed-agreement-MMDDYYYY.pdf; corrected or rebuilt copies get a -corrected / -vN suffix and older copies are never deleted automatically.

Command Center

On signature the signed offer is written to the client record (that is what shows it in the Invoice panel). Needs COMMAND_CENTER_RECORD_TOKEN on Railway matching the Command Center's PROSPECTOR_RECORD_TOKEN.

If something stops working