Inbound SMS from a client to the owner's email, and optionally onto the order — four options costed

[TortoiseWolfe]

Not started. This is a decision doc — pick an option, then it becomes work.

What we want

A client texts from their phone; it lands in the owner's email, which is the system of
record and is reachable over MCP. Ideally photos come too, since the whole point of the
intake step (#560) is "show us what you have."

Owner already uses Google Voice, which matters — option B may already be half-done.

The four options, honestly compared

	Inbound SMS	Photos (MMS)	Attaches to the order	Recurring cost	Build
A. Twilio, SMS + MMS	yes	yes	yes	~$1.15/mo + ~$0.008/msg	5th webhook, media download, bucket write
B. Google Voice → email	yes	unreliable	no	free	none
C. Phone field only	no	no	n/a	free	one field
D. Twilio, SMS only	yes	no	text only	~$1.15/mo + ~$0.008/msg	5th webhook, no media path

A — Twilio with MMS

For: the only option where a roofer standing on a roof texts three photos and they land
on the order, visible in /admin/orders next to everything else. Beats a file picker on a
phone by a wide margin. Resend is already wired for the email leg, and the webhook shape is
already established by stripe-webhook / paypal-webhook / the Calendly one in #562.

Against: it is a fifth webhook — #562 already flags the maintenance cost of the
fourth. MMS media arrives as a Twilio-hosted URL that must be fetched and written into
intake-uploads, which drags in the ownership-verification and cap work from #560. A2P 10DLC
registration is required for US business messaging and is genuinely annoying — expect a few
days and a form.

B — Google Voice

For: free, works today, zero code, and already in use. For a solo operator this may be
entirely sufficient.

Against: no API, so nothing can attach to an order — the text lands in a mailbox and a
human connects it to the job. MMS-to-email forwarding is inconsistent and has silently
degraded before. Tied to a personal Google account rather than the business, and Google's
ToS discourages business use, so it is not something the template can recommend to forkers.

C — Phone field only

For: free, immediate, no infrastructure. Click-to-call or text them from your side.
Note the catalog already promises Landing Page ships with click-to-call, so the field itself
is needed regardless — this part is being done in Phase 1 (#557), independent of this
ticket.

Against: no inbound tracking at all. Conversations stay in your phone, which is the
problem this issue exists to solve.

D — Twilio, SMS only

For: most of A's benefit at a fraction of the complexity. Text arrives, gets forwarded
to email, correlates to an order by phone number. No media download, no bucket write, no
attachment ownership work.

Against: photos still go through the web uploader, so the "text me the photos" flow does
not exist. Same A2P 10DLC registration burden as A.

A recommendation, for when you come back to it

Start at D, not A. It buys the actual ask — inbound text visible in email, correlated to
an order — without pulling in the media pipeline. If the photo-by-text flow proves valuable,
A is a strict extension of D rather than a rewrite.

Keep B running in the meantime. It costs nothing and is already working.

Prerequisites

• The phone field itself: Phase 1 (Feature 050 Phase 1 — unblock the sale: raise the ceiling, add products and orders #557), already scoped, not blocked on this.
• Any Twilio option needs the number as forker-supplied config, same pattern as Stripe,
  PayPal and Calendly — plus a TWILIO_* entry in the edge-function secrets template.

Related: #555 (epic), #557 (phone field), #560 (attachments), #562 (webhook #4).