Skip to content
imessageapi

Using iMessage group chats for jobs with more than one decision-maker

Renovations, weddings, family care, commercial work — the jobs where every update currently gets forwarded three times and someone still misses it.

6 min readUpdated August 9, 2026Playbooks

Plenty of small-business work has two or three people on the customer side. Two homeowners. A couple planning a wedding. Adult children coordinating care for a parent. An office manager and the person who signs off the budget. Messaging one of them and hoping it propagates is how schedules slip.

What a group thread fixes

  • Everyone sees the same update at the same time, with the same wording.
  • Decisions happen in the thread instead of in a phone call you were not on.
  • The full history is visible to all parties — which resolves most 'you never told us' disputes before they start.
  • Photos of progress land once, at full resolution, for everybody.

Consent is per person, not per group

Adding someone to a group thread does not give you consent to message them. Each participant needs their own consent record, and each needs a way out that does not require leaving a chat their family is using. Ask before you add anyone.

How to run one well

  1. Name the thread after the job. '14 Oak St — kitchen' is findable in six months. 'Acme Builders' is not.
  2. Open with the roles. Who you are, who else is on the thread, and what it is for. Ambiguity in a group chat is expensive.
  3. Post milestones, not chatter. Start, delivery, inspection, completion. Day-to-day questions belong in a one-to-one thread with whoever asked.
  4. Confirm decisions in writing in the thread. 'Confirming: tiles are the matte grey, going in Thursday.' That line has ended more disputes than any contract clause.
  5. Close it out. When the job ends, say so, thank them, and stop posting. A dormant group thread that suddenly gets a promotion is a genuine breach of the implied deal.

Provider support varies

Group messaging is the capability that differs most between providers, and it is the one most likely to be marked partial in our comparison table. If group threads are core to how you work, verify creation, participant management and inbound attribution against the vendor's live docs before you commit.

One practical detail that catches people out: inbound webhooks from a group need to tell you which participant sent the message, not just which thread it came from. Confirm that field exists before you build any logic on top of it.

Next step

Generate a tagged link for whatever you send next with the UTM builder, see what this looks like in your industry, or compare the services that can send it on the providers page.