Design the lifecycle before the database
- Decision
- Map decisions, owners, states, and handoffs before creating records and views.
- Why
- A flexible tool can reproduce operational confusion just as easily as it can resolve it.
Case study · CRM, ERP-lite, and operations automation
Victus Global — CRM / ERP-lite Operations System
Designing lifecycle logic, approvals, role-based visibility, automation, and handoffs around the way the business actually operated.
Systems Designer — No-Code, Automation & AI Workflows
- DeliveredOperations system and governance
- Sanitized reconstructionPublic case study
01 · At a glance
The operating context
- Organization
- Victus Global
- Role
- Systems Designer — No-Code, Automation & AI Workflows
- Period
- Selected engagement
- System type
- CRM, ERP-lite, and operations automation
Maturity and public status
- DeliveredOperations system and governance
- Sanitized reconstructionPublic case study
02 · Context
What the environment demanded
The business needed connected operational logic across intake, approvals, client and project creation, customer success, follow-ups, role-based work, and procedures.
The value was not the novelty of a no-code platform. It was the lifecycle design, governance, visibility, and adoption model built around the business.
03 · The real problem
The risk was larger than a messy workflow.
A Notion-centered CRM and ERP-lite operating system connecting intake, approvals, client and project creation, customer-success handoff, follow-up, SOPs, and role-specific work.
Records, approvals, projects, client context, and follow-ups were difficult to connect.
Different roles needed useful views without duplicating the underlying truth.
Lifecycle transitions and customer-success handoffs depended on memory and manual coordination.
Automations needed to preserve approvals and operating ownership.
04 · Ownership
What I owned
I owned the framing, operating logic, constraints, acceptance model, and delivery direction. Implementation was completed with engineering and/or AI-assisted tools according to the engagement context; I do not claim to have hand-written every line.
- Designed the CRM and ERP-lite data and lifecycle model.
- Mapped intake, approval, project creation, client creation, and customer-success handoffs.
- Created role-based dashboards and follow-up workflows.
- Directed n8n and Google Workspace connections.
- Built the operational handbook, SOP structure, and governance rules.
05 · System map
Boundaries before integrations.
Approved intake creates linked client and project records in the operating system. Role-based views expose the same underlying truth to the right people, while automation supports follow-up and customer-success handoffs under documented governance.
Intake and approval
Captures requests, required context, decision owners, and approval evidence.
Boundary: Records do not progress into committed work without the required decision.
Client and project records
Creates linked operational entities after approval and preserves lifecycle context.
Boundary: Shared records support multiple views without creating duplicate truth.
Role-based operations
Surfaces the right work, follow-up, and exception context for each role.
Boundary: Visibility follows operational need and record ownership.
Handoff and continuous service
Connects delivery to customer success, follow-up, SOPs, and lifecycle automation.
Boundary: Automation supports the handoff but does not replace required approvals or owner judgment.
Systems in context
- Notion
- CRM, ERP-lite records, work views, SOPs, and governance
- n8n
- Approved lifecycle automation and handoffs
- Google Workspace
- Documents, communication, and operating inputs
- AI-assisted tools
- Structured support for repeatable operational work
06 · Decisions and rationale
The judgment behind the system.
Tools change. The durable work is deciding what owns truth, what may move, what must stop, and what evidence is enough.
Use one record, many role views
- Decision
- Create role-based dashboards from shared underlying entities.
- Why
- Teams need different working views, not competing versions of the same client or project.
Gate record creation through approvals
- Decision
- Create downstream client and project structures only after the relevant decision is captured.
- Why
- Premature creation introduces clutter, false commitments, and unclear ownership.
Pair automation with an operating handbook
- Decision
- Document what each automation does, its owner, its exception path, and the manual fallback.
- Why
- Operational adoption depends on knowing how the system behaves when the normal path breaks.
07 · Implementation
How the model became executable
- Mapped the operating lifecycle and translated it into linked Notion entities.
- Built role-specific dashboards from shared records.
- Connected approved intake to client, project, customer-success, and follow-up workflows.
- Directed n8n and Google Workspace integrations around defined approvals and handoffs.
- Created SOP and operational-handbook structures for adoption and exception handling.
Guardrails
Where the system must stop
- Approval precedes downstream record creation where required.
- Role views do not duplicate the underlying truth.
- Automations retain a named owner and manual fallback.
- Public framing emphasizes business logic and governance, not no-code novelty.
08 · Outcomes
What changed
- Connected intake, approvals, client and project creation, customer-success handoff, and follow-up in one operating model.
- Created useful role-based visibility without duplicating core records.
- Made lifecycle rules and exceptions easier to operate through SOPs and governance.
- Turned flexible tools into a structured business system rather than a collection of disconnected databases.
09 · Evidence register
What the public record can show
Evidence is described conservatively. Any visual proof added to this page must be redacted, captioned, and checked before publication.
Diagram
Lifecycle architecture
Shows decision gates, record creation, role views, handoffs, and exception paths.
Sanitized evidence
Role-view reconstruction
A sanitized example of how shared records support distinct operating responsibilities.
Narrative record
Governance narrative
Explains the relationship between automations, approvals, SOPs, ownership, and fallback behavior.
10 · What this proves