Name the service outcome before the interface
“Centralize messages” is not an outcome. Start with a narrow need such as “a named owner can acknowledge an approved type of client request, maintain a shared current status, and recover it if that owner is unavailable.” Then list what stays outside the proposed system: sensitive records, new commitments, private conversations, or unapproved integrations.
Test the same requirement in the current workflow with a shared record and in an authorised configured or assisted path. Preserve the evidence for both. A custom layer is not eligible until those paths fail the same stable requirement, not merely because their interfaces are inconvenient.
Apply hard stops before a convenience score
Stop at do not build if any of these is unknown:
- The role that owns the authoritative service decision.
- The data classes, access roles, retention, and recovery contact.
- The action for a wrong, duplicate, missing, or delayed message.
- The operating owner who will support the resulting workflow after launch.
One failed hard stop cannot be averaged away by a polished inbox or a long list of desired features. See No Operational Owner, No Custom App for the broader ownership gate.
Prefer the smallest coherent change
The smallest useful change may be a request ID, an assigned owner, a shared status record, an acknowledgement rule, and a recovery path. It could be a configured workflow rather than a new application. If the team cannot show where the current record lives or who can change a client commitment, clarify those matters before selecting a tool.
This decision record does not rank vendors, certify access controls, promise a response time, or recommend importing historic messages. An operations owner and a security-conscious technical advisor must review an authorised non-production example before any build decision.
Client-message-inbox decision record
| Path | Same requirement | Evidence retained | Result |
|---|---|---|---|
| Current workflow plus shared record | __________ |
__________ |
Unknown / sufficient / insufficient |
| Configured or assisted workflow | __________ |
__________ |
Unknown / sufficient / insufficient |
| Narrow custom layer | __________ |
__________ |
Not yet eligible |
Does a shared inbox become the system of record automatically?
No. It may hold messages while status, authority, delivery, and recovery are still unknown. Define and test those separate responsibilities.
When can a narrow custom layer be considered?
Only after the existing and configured paths both fail the same approved requirement, every hard stop is satisfied, and an accountable owner accepts the support and recovery responsibility.