Wechat Work External Contact Bundle Laravel Package

Product Decisions This Supports

• Channel strategy / market fit. WeChat Work (企业微信) "external contact" (客户联系) is the API surface for managing customers outside the org: external contact lists, tags, customer acquisition QR codes, group chats, customer transfer between reps, and message push. If our target buyers run sales or support on WeCom, this package is the integration layer that makes that channel addressable. If they don't, this is not a decision we need to make yet.
• Build vs. buy (really: adopt vs. fork). Hand-rolling a WeCom external-contact client means token/cache management, callback signature verification and decryption, pagination quirks, and ongoing chase of API drift. A community bundle front-loads that work. But at 0.0.x we should assume we may end up owning the code — so frame it as "cheap prototype now, fork budget later" rather than a clean buy.
• Roadmap enablement. This unlocks a cluster of discrete features we'd otherwise defer: capture a lead from a rep's contact-me QR into CRM, sync external contact tags into our segmentation, detect customer churn via contact-deleted callbacks, and attribute revenue to WeCom group activity. Each is a separate roadmap item gated on this one integration.
• Use cases to validate against: B2B sales CRM with WeCom as the rep-facing front end; customer service desks where conversations start in WeCom; marketing attribution on WeCom group chats.
• What this release does not support: any decision. 0.0.1 → 0.0.2 ships a changelog link and nothing else — no features, no fixes, no breaking-change notes. Treat the release as a heartbeat, not a signal.

When to Consider This Package

Adopt (cautiously) when:

• WeCom is where your customers and reps actually are, and external contact is the primary channel rather than an afterthought.
• You need server-side access to the external contact API specifically: contact lists, tagging, customer transfer, group chat lists, contact-me QR codes, and message push.
• You can live with 0.0.x maturity — pin the exact version, read the source, and hide it behind your own adapter interface so it's swappable when it stalls or breaks.
• You've verified framework fit. The "bundle" naming suggests Symfony/PSR-style wiring rather than a Laravel package; confirm it installs and autoconfigures under Laravel, and budget a service-provider shim if it doesn't.

Look elsewhere when:

• You need WeCom internal-org APIs (messaging, approvals, OA) — different scope, different package.
• You need vendor support or an SLA. This is a community package on a 0.0.x line whose latest release note is a diff URL.
• You're on a long-lived LTS and can't absorb an unstable dependency — write the client in-house against WeCom's official docs, or pick a broader, more actively maintained WeCom SDK.
• First-party/official SDK coverage already exists for your use case.

How to Pitch It (Stakeholders)

Executives: The question isn't really "should we use this package" — it's "is WeCom external contact a channel we're selling into?" If yes, this is a low-cost shortcut to a working integration and worth a short spike. Be clear on the risk: it's version 0.0.2, the release notes are a bare changelog link, and there's no evidence of support or a stable API. Plan on possibly owning a fork. Prototyping is cheap; productionizing is moderate and carries maintenance risk we should staff for.

Engineering: A PHP package wrapping the WeCom external contact API. Early-stage: 0.0.2 contains no documented features, fixes, or deprecations, so the changelog tells us nothing about direction or stability — assess the repository itself, not the release. Recommend a timeboxed spike: install it, confirm it runs on our Laravel version, verify coverage of contact list / tags / transfer / QR / callbacks, then either adopt it behind an internal interface or fork. Do not take a hard dependency without pinning the version and reviewing the source.