The demo portal shows product screens with a sample organization. When it is open, sign-in goes to the address of the first active demo organization. If there is no demo organization, the buttons fall through to the contact form. Live customer data does not sit in the demo account. Review means reading form and step layout on sample records; a period report or reward budget is not built from those rows. HR and quality use the demo as a training tool before go-live; production decisions come from the live list.
Sample records are for training and review. Reference numbers may carry a sample prefix. Review steps and point movement follow sample rules. Those rows are not the source of a live report. After go-live the quality board asks for its own list; the close count on the demo is not written as a company claim. Sample branch, sample unit, and sample benefit type are not copied into the live tree; they are rewritten in company language on live.
In live setup each organization has a dedicated database. Record, comment, point, and attachment rows are not visible to a neighboring organization. SSL protects sign-in details and the form. An authorized user sees only their own organization. In an audit, “we saw it on the demo account” is not evidence; live references and step history are required. Before an audit, HR exports the live list into the archive.
The cloud offers a dedicated web address or a sign-in path on the main site. The IT team does not host an application server; operations run on the service side. On a company server the software sits on a company machine; data stays inside the company boundary. The marketing site can be closed in that setup. Both paths open the same form, step, and report line; deployment form does not change field layout.
Before go-live, the unit list, roles, and review steps are completed. Benefit types are written in company language; there is no category field. Unused modules stay closed. Point rules are optional; the program can open with an empty rule set. The company → branch link is set on the form; with one company or one branch the choice is hidden.
HR writes the live-opening checklist: unit tree, membership, role assignment, step owners, benefit-type list, optional catalog item. A missing unit row breaks branch or department selection on submit. If a role is empty the task list stays empty; the record enters the queue but nobody can open it.
Corporate identity is logo, color, and typeface. The demo theme is not carried into live; the company file is uploaded. Staff see their own brand. Notices land in the portal inbox. Notice text is written in live language; sample demo notice text is not copied and published. At live opening HR writes the logo file and primary color on the checklist; missing identity makes the training screen look foreign.
Field guidance on the live form is pulled into company language. Training covers current state, proposed improvement, and expected benefit. Kaizen asks for before and after measures; a suggestion is an idea not yet applied. Near miss is a type on the HSE record; place, hazard, and first action are written. A success story is the summary of applied work; a sample story on the demo is not a live source reference.
On live, the reviewer writes a step note and a rationale. Pressing a decision button during demo review is training; that decision does not move into live history. The due date is written from the step day count when the task opens. Duration labels on demo tasks are a sample calendar; the live overdue badge sits on a separate file. Quality checks the first live queue for closes without rationale; an empty rationale is a weak row in an audit.
A common mistake is treating the demo as live and writing the staff list there. A second mistake is reading the demo balance as a reward budget. A third mistake is placing a demo branch name into period comparison as if it were a real location. A fourth mistake is skipping the contact form and handing out the demo account as a production address. A fifth mistake is asking to move a demo review decision into live history; the decision stays in training. A sixth mistake is putting a demo export into the audit file; an audit asks for live references.
Backups and maintenance run on a schedule. On a company server, updates apply with internal-network approval; a package does not download automatically from outside. On the cloud, versions advance on the service side. Form and step layout do not change with deployment form. A maintenance-window notice lands in the portal inbox; the demo account is not the recipient of that notice. HR puts the maintenance day on the notice calendar; the review queue is held deliberately in that window.
On the contact form, deployment preference, headcount scale, and schedule are written. Price is clarified in that conversation. A demo review does not replace an order; live opening is a separate step. Deployment preference is cloud or company server; both are the same product line. Headcount scale guides the license or capacity talk; it does not change form fields.
In live, demo data can be separated and deleted. Catalog defaults (benefit types and similar) are real ready data; an authorized person adds them from administration. The demo account domain is not given to a live user. Sample user passwords are not carried into live. Membership invites reopen with live email addresses. After go-live, quality confirms that a sample reference prefix no longer sits on the list; if it remains, the row is separated.
Module relations can be read on the demo, but the live menu follows company settings. Suggestion may be open while kaizen or success story arrives closed. Point rules and workflow screens for a closed module are hidden. Not every item visible on the demo menu is required in live; HR marks modules to open on the checklist.
The period meeting is built from live lists. Sample charts on the demo dashboard are not put on the agenda. A silent unit is read from a zero-submit row in the live period. Average close time is calculated from live step history. An audit asks for live reference number, person, and time stamp. A demo screen capture is not added to quality-board minutes; the evidence is the live file.
Reporting on the demo shows sample figures. In live, the figure is the record at that moment. No forecast sentence is produced. Excel export depends on permission; a demo export is not added to the live archive. The branch filter runs on the live company → branch link; a sample demo branch name is not written into the live tree. Benefit-type spread is also read only from the live list; there is no category field.
In the first week after opening, HR re-reads the live checklist. Unit, role, and step owner are checked for completeness. First submits carry a due date on the task list. The first rejection or revision rationale stays on the file. If a catalog item exists, hold on request, finalize on approval, and refund on refusal are verified on the live balance. The demo balance does not enter that check.
In a training session the demo comes first, then the live address is separated. The trainer states which screen is the sample. When participants move to live they see their own unit and branch. If staff are written into the demo account by mistake, the row does not move to live; membership reopens on live. Password policy on live follows company rules. At the end of training HR signs the live checklist; a missing row delays opening.
Access is through an address set up for the organization or a sign-in path on the main site. Both reach the same portal. There is no mobile application or desktop install disc. The portal runs in the browser. In a local training session the demo is opened; the production address stays in a separate tab so the two do not mix. SSL protects live sign-in details. An authorized person writes the live address in the staff notice; the demo address does not enter that notice.
In short: the demo is a sample organization; live is a dedicated database and company identity. Data does not mix. Cloud or company server opens the same product line. Unit, role, benefit type, and steps are written before live. Audit and period report are read only from live records. A sample row is not a live claim or budget source.