Success framework
The middle is the transaction.
Replace the jump from “AI answered” to “business saved money” with an accountable chain. A reply is useful only when the next person or system can act on it.
The operating loop
- 01A useful conversationCorrect facts and complete intake
- 02An accepted next stepNamed person acknowledges the request
- 03A reconciled outcomeAppointment, job, file or invoice completes
- 04A sustainable serviceClient benefit and supplier margin persist
Recommended decision
Accept the handover and complete the transaction before counting the benefit.
The success chain
These are proposed operating targets to agree after baseline discovery. They are not grant-award thresholds.
| Stage / denominator | Proposed pass criterion | Owner and evidence | Failure action |
|---|---|---|---|
| Demand / all in-scope enquiries | Enough volume and value to cover all-in cost; exclude spam/tests consistently | SME owner: enquiry log, sample workflow, budget | Choose a cheaper scope or stop; low volume is not fixed by more agents. |
| Knowledge / agreed scenarios | ≥95% correct on agreed set; zero critical price, safety or contractual errors in that set | Business owner: signed answers, source/version and scenario results | Correct the source/policy; any critical error blocks launch. |
| Intake / eligible requests | ≥90% contain agreed required fields without unnecessary re-asking | Operations lead: request ID, fields, context continuity | Route incomplete requests visibly; include repair effort in labour. |
| Handover / all triggered handovers | 100% of critical tests route correctly; ≥95% of pilot handovers acknowledged within agreed staffed SLA | Named operator: receipt, acknowledgement, queue age | Escalate to backup owner; customer receives truthful status. |
| Progression / all eligible transactions | ≥80% use new workflow; ≥90% of accepted handovers require no reconstruction | Process owner: linked appointment/job/case IDs and rework tags | Fix missing fields or ownership before expanding acquisition. |
| Outcome / completed transactions | Correct attended appointment, completed job/invoice or reviewed complete file; no duplicates in agreed retry tests | Operations/finance: completion and reconciliation | Rollback automation; keep history and work in the human process. |
| Benefit / comparable workflow cohort | ≥20% reduction in net active labour after correction, supervision and failed handover; realised benefit supports price | SME sponsor: matched baseline/pilot and realisation plan | Reduce price/scope or stop if conservative economics fail. |
| Retention / paid client cohort | Renew/expand based on observed value; positive delivery contribution for CyberG7 | Both sponsors: actual cost and renewal decision | Do not scale a loss-making support model or a grant-dependent renewal. |
Measure work, not just speed
Net time recovered = baseline active handling − new handling − corrections − supervision − extra handover work. Waiting time is a separate customer-service measure. One interrupted conversation is not several new leads.
| Outcome | Correct unit | How to avoid overstating it |
|---|---|---|
| Receptionist | Resolved eligible question or accepted request | A receipt is not a human acknowledgement; an invitation is not a booking. |
| Booking | Confirmed appointment, then attendance | Count only genuinely incremental completed appointments as added contribution. |
| ERP | Completed job correctly invoiced without reconstruction | Invoices issued and cash received are distinct; do not claim faster payment from drafting alone. |
| Casework | Complete file accepted by the consultant | No AI eligibility verdict; count review/rework labour and document retrieval. |
| Capacity | Hours assigned to named productive work | Unchanged payroll means no salary saving. Avoided overtime requires evidence it was previously paid. |
| Acquisition | Qualified opportunity, won client and contribution | AEO score, ad click and dashboard conversion are not causal proof of extra sales. |
A small, credible measurement protocol
- Before funding commencement: collect existing records and requirements for the proposal without implementing the funded workflow. Clarify any paid discovery boundary before charging.
- Baseline: two representative weeks; tag task type, volume, active minutes, correction and outcome. Use longer or matched historical periods for low-volume/seasonal businesses.
- Pilot after the agreed submission/approval decision: four weeks with a shadow or staggered rollout, representative transactions and complete eligible denominators.
- Weekly: review every critical exception and a consistent sample of routine cases. Do not remove failures from the productivity denominator.
- Decision: report before/after distributions, workload mix, adoption and confidence limits. Compare an untreated group where practical; avoid claiming causality when only a before/after comparison exists.
- Benefit review: finance validates avoided spending; the process owner validates productive redeployment; sales validates incremental contribution and demand.
Seven gates before expansion
| Gate | Required evidence | Decision |
|---|---|---|
| Discovery | Verified bottleneck, baseline volume, existing-system capability, operator coverage | Proceed only with a real problem and a sponsor. |
| Economics | 24-month all-in cost, zero-grant scenario and conservative benefit | Agree buyer payback limit; 24 months is a planning screen, not a universal rule. |
| Funding | Applicant checks, exact activity, vendor route, timing, itemisation | Client decides self-funded or application-first before any implementation/payment. |
| Production readiness | Signed knowledge, persistent intake, tenant controls, acknowledgement, monitoring, export and rollback | Demo settings closed; current gaps resolved and witnessed. |
| Pilot acceptance | End-to-end transactions, rework-adjusted labour, access/critical tests | No critical failures; owner signs actual performance. |
| Expansion | Next bottleneck and positive current recurring economics | Add only the missing capability; retain one authoritative record per object. |
| Claim | Award → deliverable → acceptance → invoice → full payment | SME submits complete evidence; claim approval remains external. |
CyberG7’s own success criteria
| Measure | Proposed management target | Why it matters |
|---|---|---|
| First 90 days | Three paid pilots; each positive contribution | Pilot count without margin and usage is not a scalable business. |
| Activation | Each has a signed answer set, usable handover and live outcome report | Prevents sales from outrunning delivery. |
| Repeatability | Same core package, bounded integrations, documented exception policy | Excessive custom work destroys the reference-cohort strategy. |
| Recurring margin | Target ≥60% on service revenue after model, hosting, support and monitoring | Track pass-through costs separately; include founder labour at a real rate. |
| Retention | Two renewals/expansions and one permissioned case study | Actual adoption and value should precede wider paid acquisition. |
| Support burden | Track hours, incidents and corrective changes per tenant | Repeated escalations may mean poor scope or knowledge, not too little automation. |
Example planning unit economics: S$350 monthly service revenue less S$25 hosting, S$25 model allowance, S$35 tooling and one support hour at S$50 leaves S$215, or 61.4%. Four support hours reduce the margin to 18.6%. These are assumptions to validate, not observed costs or a published price.
Separate the sales clock from the approval clock
Three pilots in 90 days are a commercial learning target. They do not meet the five-client reference condition. Build five independent SMEs using the same product, collect six months of current use, meet the vendor/solution criteria, then enter evaluation.
Oct–Dec 20263 paying pilots
By Jan 20275 same-package clients
Around Jul 20276-month reference evidence
Nov–Dec 2027Illustrative evaluation outcome
The final dates assume all five are live by January, remain active, satisfy the productivity/reference requirements and the ready application takes four to five months. They are not an approval promise. Incorporation age, financial stability, support, security and functional requirements may extend the sequence.
Source: IMDA vendor criteria ↗ · IMDA pre-approval guide ↗ · IMDA chatbot checklist ↗