# Use Case: Website CRM & E-Commerce Campaign Workflow

URL: https://cloud28.ai/use-case-website-workflow.html
Category: Website workflow
Reference outcome: 3-day delivery path (system map → campaign build → QA, docs, and handover)
Owner/operator: Cloud Nine Software · Contact: sales@cloudninesoftware.vn

## Summary

How Cloud28.ai documents an inherited website and turns a static product CMS into a controlled campaign workflow — with cart activation, raffle logic, leaderboard visibility, release control, rollback, and admin handover.

## Client Profile

- Client: a business with an inherited CMS website that showed products but was hard to extend safely.
- Workflow: product batches, cart-based purchase flow, referral or raffle eligibility, winner selection, leaderboard, admin workflow, and release control.
- Starting point: shopping cart turned off, limited documentation, unclear release history, and limited rollback confidence.
- Cloud28.ai role: map the system, add agents to the delivery workflow, build the campaign features, document admin usage, and establish safer releases.

## Why This Website Needed Cloud28.ai

The website could display products, but it did not operate as an active e-commerce campaign system. The business needed a workflow for product batches, cart purchasing, raffle eligibility, winner selection, leaderboard visibility, and admin control. Cloud28.ai's first job was to make the inherited system legible; once the structure, data objects, update paths, and release behavior were documented, agents could support feature delivery without guessing inside an undocumented CMS.

## Current State

| Area | Before Cloud28.ai | Operational friction |
| --- | --- | --- |
| Product display | Products were placed in a CMS website. | The site could show products but did not run a complete selling campaign. |
| Cart behavior | Shopping cart was turned off. | Visitors could not complete a website purchase flow. |
| Campaign setup | No structured product batch workflow. | Campaign launches required manual coordination outside the site. |
| Raffle workflow | No built-in eligibility, winner selection, or announcement flow. | Promotions were hard to run, audit, or explain. |
| Leaderboard | No sales or campaign leaderboard. | Managers lacked a live view of campaign performance. |
| Release control | Unclear source history, backup, deployment, and rollback process. | A failed change could become a production recovery problem. |

## What Cloud28.ai Adds

| Capability | What Cloud28.ai adds | Business result |
| --- | --- | --- |
| System map | Document code paths, content rules, data objects, and release behavior. | Future changes start from known context. |
| Product batches | Create campaign-level product batches and status controls. | The business can run bounded product campaigns. |
| Cart activation | Reconnect the purchase flow to the campaign model. | The website supports active e-commerce behavior. |
| Raffle logic | Connect eligible activity to winner selection and announcement. | Promotions become traceable and easier to operate. |
| Leaderboard | Show campaign performance by seller, team, product, or batch. | The campaign becomes visible to managers and sellers. |
| Release control | Add source control, deployment checklist, backup, rollback, and handover notes. | Changes become safer to ship and easier to recover. |

## Three-Day Delivery Path

- Day 1 — System discovery, website map, repo structure, data objects, and release baseline. Acceptance signal: the team can explain where changes attach and how releases recover.
- Day 2 — Build product batches, cart behavior, raffle logic, winner announcement, and leaderboard flow. Acceptance signal: campaign workflow works against representative product and sales examples.
- Day 3 — QA evidence, admin user manual, backup, rollback, production deploy notes, and handover. Acceptance signal: admins can operate the campaign and the team has a recovery path.

## Measures to Track

| Measure | Baseline | Target signal |
| --- | --- | --- |
| Website knowledge | Undocumented CMS behavior. | Core system map and admin notes stay current. |
| Cart path | Cart turned off. | Customers can complete the intended e-commerce campaign flow. |
| Campaign setup | Manual coordination outside the site. | Product batch setup is controlled from the website workflow. |
| Raffle trust | No built-in eligibility or winner path. | Eligibility and winner selection are traceable. |
| Release safety | Unclear backup and rollback steps. | Each production release has source history and recovery notes. |

## Terminology

This use case uses "e-commerce campaign workflow" because the customer problem is concrete: activate online buying behavior and campaign operations inside an inherited website.