Komunikacja z klientami w Open Mercato: wiadomości, e-mail i skrzynka współdzielona

Dowody i słownik

Oddziel stan kodu, kontrolę projektu i odpowiedzialność zewnętrznego dostawcy.

• 1. released
• 2. reviewed current develop
• 3. implementation-dependent
• 4. provider or external control
• 5. not established
• 6. documentation drift

Zdefiniuj identity, właściciela, cykl życia i dowód. Podobne słowa nie tworzą tej samej domeny.

• 1. message
• 2. conversation
• 3. email
• 4. CRM interaction
• 5. Inbox Ops proposal
• 6. notification
• 7. ticket or case
• 8. campaign
• 9. observed business outcome

Cztery warstwy komunikacji

Zapisz dopasowanie, autorytet, prywatność, hand-off, awarie, uzgodnienie i stop conditions.

• 1. Internal Messages
• 2. Personal connected mailbox
• 3. Tenant-shared Inbox Ops intake
• 4. Custom or specialist authority

Możliwości Messages i stan aktora

Stan participant i actor wspiera współpracę. Nie pokazuje dostarczenia klientowi ani statusu obsługi zgłoszenia.

• 1. sender
• 2. To, Cc and Bcc recipients
• 3. subject and body
• 4. text or Markdown format
• 5. priority
• 6. draft and sent
• 7. thread and parent
• 8. recipient read state
• 9. recipient archive state
• 10. recipient delete state
• 11. source entity
• 12. objects
• 13. file attachments
• 14. actions
• 15. confirmations
• 16. email access tokens
• 17. search projection
• 18. email worker
• 19. events
• 20. notifications

Sprawdzony inwentarz dostawców. Dostawca spoza listy nie ma sprawdzonego adaptera.

Oba sprawdzone profile e-mail mają fileSharing: false, readReceipts: false i deliveryReceipts: false. Gmail i IMAP raportują best-effort sent placeholder. Nie dowodzi on, że dana osoba odebrała, przeczytała wiadomość lub podjęła działanie.

Prywatność i cykl osobistej skrzynki

Osobisty kanał Gmail lub IMAP jest dostępny wyłącznie dla właściciela. W sprawdzonym v1 ani admin, ani superadmin nie może działać na kanale innego właściciela. Feature communication_channels.admin jest zarezerwowany i nie daje uprawnień do kanału innego użytkownika. Enrichment zależny od participant ukrywa payload kanału przed osobą spoza rozmowy, nawet w tym samym scope. Assignment jest wskazaniem pomocniczym o określonym zakresie. Nie daje dostępu do skrzynki, członkostwa w kolejce, równoważenia pracy, nadzoru ani SLA.

Przypisz właściciela, aktora allowed i denied, zachowane dane, dowód recovery oraz krok exit.

• 1. connect
• 2. owner-only view and manage
• 3. choose primary
• 4. share one CRM email
• 5. assign a linked conversation
• 6. cover absence or leave
• 7. reconnect after error
• 8. disconnect
• 9. clear credentials
• 10. retain or export synchronized history
• 11. offboard user
• 12. transfer ownership not established

E-mail CRM jest domyślnie prywatny dla właściciela skrzynki i może być udostępniony per e-mail; sprawdzone wydanie nie ma admin override. Szersza decyzja o rekordzie i timeline należy do przewodnika CRM.

Czas mierzy się end to end

Zmierz configured delay, kolejkę, processing i widoczne przybycie w normalnych warunkach i podczas awarii.

1. 1

   provider event

2. 2

   webhook or 60-second scheduler tick

3. 3

   provider fetch or history cursor

4. 4

   queue and ingestion

5. 5

   Messages persistence

6. 6

   CRM or other enrichment

7. 7

   UI cache and notification

8. 8

   measured end-to-end arrival

Sprawdzony kod używa 300 sekund dla kanału polling-only, 60-sekundowego ticka schedulera i rekomendowanego 1 800-sekundowego fallbacku Gmail push. Inne dokumenty mówią o 60 sekundach albo 5 do 15 sekundach. Te wartości są sprzeczne i nie stanowią gwarancji poziomu usługi. Gmail watch trzeba odnawiać co najmniej raz na siedem dni, a push może się opóźnić lub zaginąć, dlatego cursor recovery i polling fallback pozostają konieczne.

Łączenie wątków i historia

Zapisz confidence, zachowanie duplicate, ścieżkę korekty i właściciela reconciliation.

• 1. provider conversation id
• 2. HMAC thread token
• 3. RFC message headers
• 4. subject and participant fallback
• 5. new thread
• 6. duplicate
• 7. orphan
• 8. wrongly joined or split
• 9. forwarded, stripped-header or cross-mailbox correction

Nowe połączenie IMAP startuje od bieżącego UID bez importu historii. Opcjonalny idempotent import ma granice 1 do 365 dni i 5 000 wiadomości oraz kontrolę concurrency. Sprawdzone wsparcie obejmuje wyłącznie IMAP; obsługi Gmail brak. Reconnect, dead letter, już zsynchronizowana historia i cursor recovery to osobne stany.

Model stanów komunikacji

Nie zamieniaj technicznego stanu pośredniego w dostarczenie klientowi ani poprawność biznesową.

• 1. message row state
• 2. recipient-specific state
• 3. channel connection state
• 4. provider acknowledgement state
• 5. thread-match confidence
• 6. proposal and action state
• 7. observed business outcome

Kontrole wdrożenia Gmail i IMAP

Gmail wymaga konfiguracji OAuth projektu, zgody użytkownika, obsługi refresh token i opcjonalnego Pub/Sub watch. Google klasyfikuje obecny scope gmail.modify jako restricted; przy przechowywaniu lub przesyłaniu tych danych mogą obowiązywać verification i security assessment. Ustal z Google, jakie obowiązki dotyczą konkretnego wdrożenia, w tym weryfikacja lub ocena bezpieczeństwa.

IMAP/SMTP wykonuje live validation, szyfrowane przechowywanie poświadczeń, wybór TLS oraz host/DNS pinning przeciw internal-address SSRF. Insecure transport jest wyłączony bez jawnej zgody; escape hatch dla internal host to decyzja ryzyka operatora. Kanał polluje INBOX i wysyła przez SMTP. Provider push jest niedostępny, a próby outbound attachment są obecnie odrzucane.

Klasyfikacja scope Gmail przez Google · Limity Google watch i push

Pipeline propozycji Inbox Ops

• rfq
• order
• order_update
• complaint
• shipping_update
• inquiry
• payment
• other

• create_order
• create_quote
• update_order
• update_shipment
• create_contact
• create_product
• link_contact
• log_activity
• draft_reply

Scoped address odbiera e-mail od dostawcy lub z forwardingu, weryfikuje inbound path, parsuje wątek i prosi skonfigurowany model o kategorie, participants, discrepancies, actions i draft replies. Uprawnione osoby edytują, akceptują lub odrzucają propozycje. Każde zaakceptowane działanie nadal wymaga domain permission i walidacji command. AI confidence nie daje uprawnienia ani dowodu poprawnego wykonania lub wyniku biznesowego. Accept-all działa sekwencyjnie i zatrzymuje się przy błędzie, więc partial state trzeba uzgodnić.

Oddziel bieżący kod, decyzję projektu, kontrolę dostawcy, dowód, awarię i właściciela.

• 1. intake
• 2. authentication
• 3. tenant resolution
• 4. five-minute replay defense
• 5. 2 MB request-body limit
• 6. global and tenant rate limit
• 7. message-id or content-hash deduplication
• 8. protected body access
• 9. model and provider
• 10. prompt and data boundary
• 11. proposal permission
• 12. domain action permission
• 13. edit and concurrency
• 14. atomic send claim
• 15. Resend delivery provider
• 16. audit and events
• 17. retention
• 18. deletion
• 19. recovery and owner

Poprawnie dostarczony e-mail na znany adres dostarcza treść wejściową. Nie potwierdza autoryzacji nadawcy. Route wymaga też kontroli address abuse, spamu, malicious content, prompt injection, model data, attachments, kosztu i incydentów. Czytelnik tylko z log-view dostaje stabilny zredagowany kształt, chyba że ma również proposal-view. Translation jest model-costing persistent mutation za proposal-manage. Wysyłka reply ma osobne permission, wymaga zaakceptowanego draftu, używa atomic claim i Resend oraz zapisuje sukces tam, gdzie może. Nie dowodzi dostarczenia, obsługi bounce ani suppression.

Granica helpdesk, contact center i marketingu

Tę funkcję musi dostarczyć i odebrać nazwany moduł projektu lub system zewnętrzny. Same sprawdzone dowody komunikacji jej nie potwierdzają.

• 1. ticket or case identity
• 2. requester and organization model
• 3. team queues
• 4. assignment policy
• 5. agent presence
• 6. collision detection
• 7. ownership transfer
• 8. business hours
• 9. SLA clocks
• 10. escalations
• 11. priority policy
• 12. canned replies
• 13. templates
• 14. knowledge base
• 15. customer portal
• 16. CSAT
• 17. voice and telephony
• 18. recording
• 19. SMS
• 20. social messaging
• 21. chatbot
• 22. campaign audience
• 23. segmentation
• 24. marketing consent
• 25. unsubscribe and suppression
• 26. bounce and complaint handling
• 27. deliverability monitoring
• 28. workforce reporting

Drzewo decyzji, przepływ i odpowiedzialności

1. 1

   Name the business outcome and authoritative record

2. 2

   Choose personal, shared operational or service-team ownership

3. 3

   Select the smallest layer that preserves that ownership

4. 4

   Define privacy, provider, failure and reconciliation controls

5. 5

   Stop or integrate when missing service semantics are material

Nazwij granicę zaufania, zapisany stan, właściciela i terminal evidence.

• 1. external sender or internal actor
• 2. provider or Messages boundary
• 3. webhook, push or poll
• 4. normalized message and thread evidence
• 5. AI proposal when Inbox Ops is used
• 6. human review and domain permission
• 7. command or provider send
• 8. reconciliation and business outcome

• business owner
• mailbox owner
• team lead
• application owner
• security and privacy owner
• provider administrator
• implementation team
• support and operations owner

Syntetyczne scenariusze modelu operacyjnego

Użyj abstrakcyjnych etykiet, aby ocenić wybór, autorytet, awarie, uzgodnienie i odbiór.

Pakiet odbioru menedżera

Podaj actor, warstwę, stan providera, scope, oczekiwany stan, prohibited outcome, failure injection, dowód, cleanup, reconciliation, właściciela i pass criterion.

• 1. internal compose
• 2. internal read
• 3. internal reply
• 4. internal archive
• 5. internal actor-scoped delete
• 6. external email mode
• 7. personal Gmail
• 8. personal IMAP
• 9. multiple channels
• 10. primary swap
• 11. wrong owner
• 12. admin attempt on personal mailbox
• 13. reconnect
• 14. push loss
• 15. poll delay
• 16. token expiry
• 17. malformed inbound
• 18. duplicate inbound
• 19. mis-thread
• 20. split thread
• 21. stripped headers
• 22. cross-mailbox thread
• 23. history import day cap
• 24. history import 5000-message cap
• 25. history import concurrency
• 26. outbound attachment attempt
• 27. provider rejection
• 28. no delivery receipt
• 29. shared Inbox Ops intake
• 30. invalid signature
• 31. replay
• 32. rate limit
• 33. dedupe
• 34. inactive inbox
• 35. model failure
• 36. prompt injection
• 37. wrong organization
• 38. log-only body redaction
• 39. proposal permission
• 40. action permission
• 41. accept-all partial failure
• 42. concurrent reply send
• 43. provider send failure
• 44. offboarding
• 45. retention and export
• 46. outage recovery
• 47. local register privacy
• 48. no-JavaScript and print

Zatrzymaj lub zintegruj

• no accountable communication owner.
• required provider is not established.
• universal admin access to personal mailboxes is mandatory.
• no reconciliation owner.
• no provider-governance decision.
• no privacy or retention decision.
• no shared-queue operating model.
• no service-policy owner.
• specialist capability is required without an authoritative system.