What are the strengths and blind spots of describing a life-cycle process as plain text?

Question

Accepted Answer

Text is quick to write, needs no notation and can carry context, assumptions and caveats, but it hides gaps: prose does not force you to consider every combination of states, so missing cases go unnoticed.
A well-structured text description of the business-customer LCP has a fixed outline:

(0) Information object: what is maintained where ("the business customer is kept in the CRM as Customer with the contact person's e-mail and company").
(1) Create, (2) Update, (3) Delete: one paragraph each, naming trigger, actor, systems and result.
Assumptions: facts the process relies on, for example "the CRM keeps a change history" (needed to find a user after an e-mail change).
Notes: consequences and open points, for example "after deletion, using the shop as a private customer requires a new registration".

Its honesty is also its limit. A typical note reads: the handling of user objects created through self-service is only hinted at here; the details must be aligned with the account and password LCPs. Text lets you write that sentence and move on. A state table would force you to fill in a row for "user created in self-service, then sales creates the customer", which is exactly the case the sentence glosses over.
Tip: Text is the right first draft and the right place for assumptions. Before implementation, translate it into a representation that exposes gaps (a flowchart or state table).
Go deeper:

Use case (Wikipedia) — structured textual descriptions with preconditions, a main success scenario and alternative flows, a disciplined form of process text.