Self-Service Readiness Score¶
Applies to: All subscriptions
Purpose¶
Answer the question this portal was built to answer: can a customer technical team or implementation partner successfully implement and support Complifly without contacting Complifly?
This is the deliverable for Phase 8 — Self-Service Readiness. It is written to be useful rather than reassuring, so it states where the answer is no.
Audience¶
Complifly product and documentation leadership. Partners assessing whether to take on a deployment. Customers assessing their own self-sufficiency.
Prerequisites¶
- The portal as it stands
- The Assumptions Register, which lists what could not be verified
Reference¶
The headline answer¶
Partially, and the boundary is precise.
A competent partner can design, install, configure, integrate, operate and troubleshoot Complifly from this portal alone.
They cannot procure infrastructure with confidence, complete a security review, or make a commercial commitment, because those depend on facts only Complifly holds and which are not yet published.
The gap is not in the writing. It is in a specific, enumerable set of facts.
Score by capability¶
Scores are the share of what a partner needs that this portal supplies, judged against the outcome each section promises in the Section Charter.
| Capability | Score | Judgement |
|---|---|---|
| Understand the solution | 95% | Complete. Scope, boundaries and the responsibility split are unambiguous |
| Design the deployment | 85% | Strong. Held back only by unstated version support and disaster-recovery patterns |
| Procure infrastructure | 55% | Weakest area. Sizing figures are estimates, and the database edition and runtime versions are unstated |
| Install | 90% | Strong, with verification that catches silent failures |
| Configure | 90% | The full setting surface, with consequences |
| Secure and pass review | 60% | A real gap. Architecture is well documented; policy and certification facts are not published |
| Administer users and roles | 95% | Complete and grounded in the real role model |
| Integrate an ERP | 90% | Strong. The pattern, the API and per-ERP guidance are all present |
| Operate day to day | 90% | Complete routines with owners and gates |
| Monitor | 85% | Complete coverage; thresholds are starting points until measured |
| Troubleshoot | 90% | Decision trees by symptom, with the who-fixes-it classification |
| Upgrade and roll back | 80% | Complete procedure; window durations unmeasured |
| Support end users | 85% | Strong, and complemented by the in-product help centre |
Overall: approximately 82%.
What that number means¶
| Interpretation | Detail |
|---|---|
| Day-to-day operation | Self-sufficient. A trained team should rarely need Complifly for routine work |
| Implementation | Self-sufficient on the technical path; dependent on Complifly for commercial and licensing facts |
| Procurement | Not self-sufficient. Requires figures Complifly must supply |
| Security approval | Not self-sufficient. Requires policy and certification evidence |
| Incident support | Self-sufficient for the large majority; genuine platform faults still escalate, correctly |
The high-risk gaps¶
Ranked by the damage the gap causes, not by how hard it is to close.
1. Sizing is unmeasured — high risk¶
Every figure in Sizing and Capacity is an engineering estimate. A customer sizing a production environment from estimates may under-provision at go-live or over-purchase substantially.
Closes with: a load test at each tier, published as measured figures. Assumptions A1 to A4.
2. Supported versions are unstated — high risk¶
The minimum SQL Server version and edition, and the supported Node.js range, are not published. The edition question in particular has a direct licensing cost, because tenant isolation depends on a feature not present in every edition.
A customer can buy the wrong licence on this gap alone.
Closes with: a supported-versions matrix per release. Assumptions B1, B2.
3. Security policy facts are unpublished — high risk¶
Password policy, session lifetime, lockout thresholds, audit retention, tamper-evidence guarantees and certification posture are all unstated. A customer's security team cannot complete a questionnaire, and a partner cannot answer for Complifly.
The architecture is well documented and defensible. The policy layer is missing, and it is what procurement asks about.
Closes with: a published security fact sheet. Assumptions E3, E4, E5, E2.
4. Commercial model is undocumented — medium-high risk¶
Module packaging, registration and user counting, environment entitlement, GSP call metering, and support tiers are all outside this portal. Escalation criteria throughout cite a support matrix that has not been supplied.
Closes with: a commercial and support fact sheet, including the data-processing terms. Assumptions D1 to D5.
5. Connector maturity is unstated — medium risk¶
Which ERP integrations are productised connectors and which are patterns a partner implements is not established. A partner quoting effort on the wrong assumption will misprice the work — in either direction.
Closes with: a reference-implementation status per ERP. Assumptions F1, F2.
6. Operational limits are unmeasured — medium risk¶
Throughput ceilings, upgrade window durations, and whether concurrent workers are supported are unknown. Each produces a planning error rather than a failure, but planning errors at go-live are expensive.
Closes with: measurement and a supported-topology statement. Assumptions A3, C3, C4, C5.
What is genuinely strong¶
Worth stating, because a gap list read alone gives a misleading picture.
| Strength | Why it matters |
|---|---|
| Silent failures are documented as such | Row-level security returning zero rows, a queue that stalls invisibly, help that renders nothing, a mail failure that locks users out. Each is named, with the check that catches it. This is the difference between documentation that describes a product and documentation that lets someone operate it |
| Errors are classified by who fixes them | Roughly a third of what customers meet is statutory. Saying so plainly prevents tickets nobody can close |
| Statutory constraints are separated from product limitations | Consistently, throughout. This alone should remove a meaningful share of support load |
| Validation sections demand evidence | "It ran without errors" is explicitly rejected as proof, in a product where several failures report success |
| The integration pattern is written once | Per-ERP pages carry only what is genuinely specific, so there is one place to correct and no drift |
| Assumptions are marked rather than hidden | A reader can tell a measured fact from an estimate. That is what makes the 82% trustworthy rather than a claim |
Closing the gap¶
| Priority | Action | Effort | Takes the score to |
|---|---|---|---|
| 1 | Publish the supported-versions matrix | Low | ~85% |
| 2 | Publish the security fact sheet | Low to medium | ~89% |
| 3 | Publish the commercial and support model | Low | ~92% |
| 4 | Measure and publish sizing | Medium | ~95% |
| 5 | State connector maturity per ERP | Low | ~96% |
| 6 | Measure upgrade windows and throughput | Medium | ~97% |
The first three are low-effort and account for most of the remaining gap. None requires new engineering; each requires a decision and a page. That is the finding worth acting on: the portal is not short of writing, it is short of a handful of facts that only Complifly can state.
A realistic ceiling is around 97%. The residue is genuine platform faults and novel situations, which is what support exists for.
The final question, answered plainly¶
"Can a customer technical team successfully implement and support Complifly without contacting us?"
| Activity | Answer |
|---|---|
| Understand what it does and does not do | Yes |
| Design a deployment | Yes |
| Size and procure infrastructure | No — needs measured figures and version support |
| Install and configure | Yes |
| Pass a security review | No — needs published policy and certification facts |
| Administer users and roles | Yes |
| Integrate an ERP | Yes |
| Operate day to day | Yes |
| Troubleshoot | Yes, for the large majority |
| Upgrade and roll back | Yes, though window planning is unmeasured |
| Make commercial decisions | No — needs the commercial model |
So: yes for everything technical, no for procurement, security approval and commercial decisions. Those three depend on facts Complifly holds and has not published, and all three are closed by documents rather than by engineering.
Validation¶
This assessment is honest if:
| Check | Pass condition |
|---|---|
| Every gap maps to a register entry | Traceable to the Assumptions Register |
| Scores are justified | Against the outcome each section promises in the Section Charter |
| No gap is understated | A partner reading this is not surprised later |
| Strengths are not overstated | Claims are checkable against the pages |
| It is re-scored | After each gap-closing action, and after real partner experience |
The real test is empirical: give the portal to a partner who has never deployed Complifly, and count what they have to ask. Every question is either a gap or a findability problem, and both are actionable.
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| A partner asks something the portal answers | A findability problem, not a content gap | Improve the description and keywords; link from where the question arises |
| A partner asks something the portal does not answer | A genuine gap | Add it to the register and write the page |
| The score does not improve after work | Effort spent on strengths rather than gaps | Work the priority order above |
| Customers still contact support constantly | Either the content is not reaching them, or the questions are commercial | Check which; the answers differ entirely |
| Procurement stalls repeatedly | The version and sizing gaps | These are the first two priorities for a reason |
Related Articles¶
- Assumptions Register — every gap, with what closes it
- Support Reduction Register — the question-level view
- Section Charter — the outcomes scored against
- Portal README — the portal itself