Interactive Demos

1. Incoming enquiry

A visitor submits a form: name, work email, company, and a short description of their problem.

Synthetic example: Sara, Operations Director, asks about automating order follow-up.

2. Qualification

The workflow checks the enquiry against agreed criteria: company, role, and problem type.

Result in demo: qualifies for an AI Opportunity Discovery Call.

3. CRM entry

A lead record is created with the enquiry, source, and qualification notes.

No duplicate is created for an existing contact in this example.

4. Draft follow-up

A draft reply is prepared, referencing the stated problem and proposing next steps.

Draft only — nothing is sent yet.

5. Human approval

Human checkpoint — approval required. A sales owner reviews, edits, and approves the draft. If it is not approved, nothing is sent.

Approval is required before any outbound message.

6. Logged activity

The approved message and the outcome are logged in the CRM for follow-up.

The loop closes with a named owner and a next action.

7. Edge path: duplicate contact

The enquiry matches a contact already in the CRM. The workflow proposes a merge and stops: a sales owner confirms the merge before any record changes. No duplicate record is created, and no draft is sent from a duplicate record.

Synthetic example: the same Sara Haddad enquiry arriving twice still produces one CRM record.

1. Incoming question

A customer asks: “Where is my order, and can I change the delivery address?”

Synthetic example only.

2. Approved knowledge retrieval

The assistant retrieves only from the approved help articles and order-status source.

Unapproved web sources are not used.

3. Draft response

A draft answer is prepared with the order status and the address-change options.

Draft only.

4. Confidence / risk check

The draft is checked for confidence and for policy-sensitive content.

Address changes are flagged as sensitive in this example.

5. Human escalation

Human checkpoint — escalation required. Because the request is sensitive, the case is routed to a support agent with the draft attached. The customer is not left with an unverified answer.

6. Resolution & learning

The agent resolves the case and the outcome is recorded for quality review.

Patterns feed the next evaluation cycle.

7. Edge path: order system unavailable

The order-status source cannot be reached. The assistant does not guess a status: it tells the customer plainly that the status cannot be checked right now and routes the case to a support agent with the question attached. No unverified answer is sent.

Synthetic example: order DEMO-8841 with its source down still ends with a person, not a guessed answer.

1. Document received

An invoice PDF arrives in a monitored inbox.

Synthetic invoice: INV-DEMO-1042.

2. Data extraction

Supplier, date, line items, and totals are extracted.

Extraction is a proposal, not a posting.

3. Validation

Extracted values are checked against expected formats, totals, and known suppliers.

A total mismatch is flagged in this example.

4. Human approval

Human checkpoint — approval required. A finance reviewer corrects the flagged total and approves the document. No posting happens before approval.

5. System update

The approved data is posted to the finance system and filed with the original document.

An audit trail links the original, the correction, and the posting.

6. Edge path: finance system unavailable

The approved invoice cannot be posted because the finance system is unreachable. The approved data is held, not posted, and posted only once the system is reachable again. The audit trail records the hold, the original, and the eventual posting.

Synthetic example: INV-DEMO-1042 approved but unposted stays held — nothing is recorded as posted before it is.

1. Enquiry intake

Two synthetic enquiries arrive: one clear sales follow-up need, one vague request with missing company details.

Both are recorded before any scoring happens.

2. Transparent scoring

Each enquiry is scored against published, agreed criteria — role, company fit, problem fit, and timeline — so the score can be explained and challenged.

Scores in this demo are illustrative and recorded in this demo only; they are not conversion predictors.

3. Threshold check

Demo thresholds: 75+ = high priority, 50–74 = review, below 50 = nurture / request more detail. Thresholds are agreed with the client before launch, not hidden in the tool.

Example scores: 90 (high) and 55 (review).

4. Routing

The high-priority enquiry is routed to the named sales owner with its score breakdown and source attached. The borderline enquiry is NOT auto-sent to sales.

Routing moves the record; it does not send a customer message by itself.

5. Human review of borderline cases

Human checkpoint — review required. A reviewer checks the borderline enquiry, requests the missing detail, and decides whether it qualifies. Automation proposes; a person decides.

6. Logged outcome

Scores, routing, reviewer decisions, and next actions are logged so the scoring rules can be audited and improved — and so no enquiry silently disappears.

What this demo does NOT claim: that a higher score guarantees a sale, or any improvement recorded in this demo.

7. Edge path: abusive or spam input

An enquiry is flagged as abusive or spam content. It is not scored and not routed: it is held for a person to confirm rejection, and the rejection is logged with its reason. Filtering never sends a customer message by itself.

Scores in this demo are illustrative and recorded in this demo only; a filtered enquiry receives no score.

1. Request submitted

Lina submits a purchase request with item, quantity, reason, budget code, and requested delivery date.

The request is a proposal, not an order.

2. Automated policy check

The workflow checks the budget code, the amount thresholds, and whether required fields are complete. Missing or out-of-policy items are flagged, not bypassed.

In this example the request passes the completeness check and triggers both approvals (above 250 and above 400).

3. Manager approval

Human checkpoint — approval required. The line manager reviews business need and budget, and approves with a comment. A rejection here stops the workflow.

4. Finance approval

Human checkpoint — approval required. Finance confirms the budget code and amount before any commitment. No purchase order is issued before this step.

5. Purchase order issued

Only after both approvals, a purchase order is generated from the approved request — with the approved amount, not a changed amount.

If either approver rejects, the requester is notified with the reason and can revise and resubmit.

6. Audit trail

Request, policy checks, both approvals, comments, and the purchase order are linked in one trail for later review.

What this demo does NOT claim: any saving, speed improvement, or compliance certification shown in this demo.

7. Edge path: incomplete request

The request is missing its budget code. The policy check fails on completeness, so the request is returned to the requester with what is missing — before any approval is sought. Nothing is ordered, and no approver's time is used on an incomplete request.

Synthetic example: PR-DEMO-77 without a budget code goes back to Lina, not to a manager.