Direct answer: An integration-capability page is not a robot-brand wall or a customer-logo wall. Buyers need to know what you deliver, how cycle time/yield/downtime are defined, how you connect to PLC/MES/safety systems, whether the customer-site evidence is authorised, and who owns problems. Do not name customers without authorisation, and do not publish performance numbers without a measurement basis. The page should support a technical review, not just look premium.
This report is for owners, sales, solution/pre-sales, project delivery, marketing and legal at robotics/intelligent-equipment companies in Changzhou. It covers how to accept a website "integration capability" page. Information is current to 30 October 2026. It is public policy, law and project method, not certification or a promise about any robot, integrator, project, cycle time/yield/ROI or customer case; technology, safety, contracts and customer authorisation are governed by project documents, standards, contracts and legal advice.
Write boundaries and metrics before brands. Customer names/sites/data need authorisation and scope. Cycle time, yield, downtime and ROI need a measurement basis, sample period and owner—not just one impressive number.
Why is an integration-capability page not a case wall?
A case wall answers "who have you served"; an integration-capability page answers "can you deliver to my line, interfaces, cycle time and safety requirements". It needs scope, metrics, interfaces, site evidence and service boundaries.
Robot bodies, grippers, vision, PLC, MES, safety fencing and logistics are often delivered by different parties. The buyer's real concern is whether the integrator can coordinate the interfaces, hit cycle time, define yield/downtime, own problems and allow a site visit. A robot brand and customer logos do not answer that. China's "Robot+" application action plan, issued by MIIT and 16 other departments, promotes robotics applications in manufacturing and other scenarios, but policy direction is not evidence of any integrator's project results; the website must speak with its own scope, evidence and acceptance.
| Page | Question answered | What buyers look for | Cannot replace |
|---|---|---|---|
| Product page | What the robot/equipment can do | Model, payload, reach, accuracy, speed | Integration capability, cycle time/yield |
| Case page | Who/what you have served | Authorisation, industry, scope, results | Delivery boundaries, interface ownership |
| Integration-capability page | Can you deliver to my line/interfaces/cycle time | Scope, metrics, interfaces, safety, service | A specific project promise |
| Service page | How maintenance/spares/response work after delivery | SLA, spares, remote/on-site | Project acceptance results |
Page split is an editorial method; adjust to the company's business, project types and customer decision chain.
What seven questions must the page answer?
Write seven sections—industry/scenario, delivery scope, cycle time/yield, interfaces/systems, safety, customer site, and service. Give evidence and boundaries; avoid unverifiable phrases such as "turnkey" or "unmanned".
Write the page like a technical-review document, not a brand brochure: the first screen states the line/process and delivery boundary; the second gives metric definitions and interfaces; the third gives authorised customer-site evidence; the fourth gives service and contact. Each section states "what we do / what we do not do / what the customer must provide", so the buyer can judge fit.
| Module | What to write | Evidence | Boundary |
|---|---|---|---|
| Industry/scenario | Process, workpiece, cycle-time range, changeover frequency, environment | Scenario list, authorised site photos | Do not write "all industries" |
| Delivery scope | Robot/gripper/vision/PLC/MES/safety/logistics—who supplies | Scope table, interface list | Do not claim customer systems as own |
| Cycle time/yield | Definition, baseline, sample period, measurement boundary | Test record, acceptance report | No "30% improvement" without basis |
| Interfaces/systems | PLC/MES/ERP/vision/safety signals, protocols, permissions | Interface docs, integration record | Do not promise "connect anything" |
| Safety | Risk assessment, fencing/light curtain/e-stop, CE/standards if applicable | Risk assessment, CE/test documents | Safety is not an option |
| Customer site | Visit/audit, photos/video, customer contact | Authorisation, NDA, redaction | Do not expose sensitive layout |
| Service | Spares, response, remote/on-site, training, upgrades | SLA, spares list | No unlimited/fixed on-site promise |
The seven-section structure is an editorial template; specific projects depend on process, contract, safety standards and customer requirements.
How should cycle time, yield, downtime and ROI be defined?
Write baseline, measurement boundary, sample period and statistical basis before results: cycle time as CT/UPH, yield as FPY/defect rate, downtime as OEE/fault time, and ROI including investment, operations and labour savings.
Robot integration projects easily produce conflicting numbers: the vendor says 30% faster, the customer says changeover was excluded; the vendor says 99% yield, the customer says only good parts were counted; the vendor says payback in two years, the customer says maintenance and downtime were omitted. Define the measurement: which segment, which product/batch, how long, who measures, how anomalies are handled. A number without a basis is worse than no number.
| Metric | Definition/formula | Measurement boundary | Evidence |
|---|---|---|---|
| Cycle time CT | Time per piece/batch; or UPH | Includes loading/changeover/inspection? | Line test, timing record |
| Yield FPY | First-pass good units / input | Defect definition, rework/recheck | Inspection record, sample period |
| Downtime/OEE | Fault/changeover/waiting/planned downtime | Statistical basis, responsibility | Equipment log, ticket |
| Changeover time | Last good part to first good part | Program/fixture/parameter change | Changeover record |
| Labour substitution | Reduced roles/hours/shifts | Redeployment, added inspection | Shift/time record |
| ROI | Investment/savings/ops/downtime/residual | Years, discounting, assumptions | Financial model, acceptance data |
Metric definitions are editorial suggestions; specific formulas, sample periods and acceptance bases depend on the project, customer and contract, with no fixed improvement or payback promise.
How should delivery boundaries be drawn?
List robot, gripper, vision, PLC/MES, safety, logistics, civil works and training with "who supplies/connects/accepts". Unclear boundaries turn cycle time and downtime into disputes.
The page should dare to say what it does not do. For example: who buys the robot body, who designs the gripper/end effector, who supplies vision camera/lighting, who changes the PLC program, who develops the MES interface, who installs safety fencing/light curtains, who connects logistics/AGV, who handles civil works/air/power, who delivers training/documentation. For each, state the interface, owner and acceptance evidence. The customer can then see whether you are a general integrator, a partial integrator or a specialist.
| Object | Who supplies/connects | Interface/acceptance | Common dispute |
|---|---|---|---|
| Robot body | Integrator/customer/brand | Model, payload, accuracy, delivery/commissioning | Brand specified but integration excluded |
| Gripper/end effector | Integrator/customer | Workpiece, gripping, quick change, life | Who changes when the workpiece changes |
| Vision/inspection | Integrator/third party | Camera/lighting/algorithm, samples, cycle time | False reject/miss responsibility |
| PLC/MES | Customer IT/integrator | Protocol, points, permissions, integration | Who pays for interface changes |
| Safety | Integrator/customer/EHS | Risk assessment, fencing/light curtain/e-stop | Safety standard/CE scope |
| Logistics/civil | Customer/third party | AGV, air/power, floor, space | Site conditions not ready |
| Training/docs | Integrator | Operation/maintenance/spares/handover | Machine delivered, documents not |
The boundary table is an editorial template; supply/interface/safety responsibility depends on the project contract, technical agreement and safety standards.
How should customer-site evidence/authorisation be handled?
Customer name, logo, site photos/video, line data and employee images need written authorisation with scope/term. Without it, use an anonymised industry case and do not expose customer layout, process or contacts.
Robot integration cases often include customer factory layout, cycle time, yield, product photos, employee images and contacts, which may be trade secrets or personal information. Before publishing, confirm: whether the customer authorises the name/logo; whether photos/video include faces, tooling, products or line layout; whether data is redacted; the scope/term/withdrawal of authorisation; and whether sales/customer-audit materials are separated from the public page. Without authorisation, write an anonymised "a automotive-parts company / a new-energy company" case and state that the customer name is withheld.
| Material | Confirm before publishing | Handling | Evidence |
|---|---|---|---|
| Customer name/logo | Written authorisation, scope/term | Public/anonymous/customer-audit only | Authorisation |
| Site photos/video | Layout, products, faces, screens | Redact/crop/not public | Review record |
| Line data | Cycle time/yield/downtime/capacity | Range/index/redaction | Customer confirmation, test record |
| Employee images/contacts | Portrait/personal information/consent | Blur/remove/replace | Consent/authorisation |
| Process/tooling | Trade secret/customer restriction | Not public/NDA | NDA |
| Customer testimonial | Original text/authorisation/withdrawal | Quote/anonymise | Authorisation, original |
Customer-material handling is an editorial suggestion; authorisation, personal-information and trade-secret requirements depend on the contract, customer policy and law.
How should the case card/page structure be accepted?
Each case card needs project background, workpiece/process, delivery scope, challenge, solution, metrics/basis, timeline, service and authorisation status. Without these, it is just a photo and "a customer".
The integration-capability page can be "capability overview + 3–6 case cards + service/contact". Case cards should be verifiable rather than numerous: customer/industry (within authorisation), workpiece/process, cycle time/yield/downtime basis, robot/vision/PLC scope, project challenge, delivery timeline, service/spares and authorisation status. Do not write every case from the same template; highlight the different challenge—changeover, accuracy, cycle time, cleanroom, safety or logistics.
| Module | What to write | Evidence | Common problem |
|---|---|---|---|
| Project background | Industry, workpiece, original process, pain | Customer authorisation, background | Only "a well-known customer" |
| Scope | Robot/gripper/vision/PLC/safety/logistics | Scope table, interface list | Counting customer systems as own |
| Challenge | Changeover, accuracy, cycle time, space, safety | Solution/review record | Every case is "high difficulty" |
| Metrics | Cycle time/yield/downtime/labour, with basis | Test/acceptance report | No baseline/sample period |
| Timeline | Design/build/install/commissioning/volume | Project plan | Only "fast delivery" |
| Service | Spares, response, training, remote/on-site | SLA, spares list | Only "lifetime service" |
| Authorisation | Public/anonymous/customer-audit only | Authorisation, redaction record | Logo without authorisation |
The case-card structure is an editorial template; project content, metrics and authorisation depend on the customer/contract, with no invented customers or results.
Pre-publication acceptance checklist
Before publishing, check scope, metric basis, interfaces/safety, customer authorisation, case evidence, service and old-version takedown. If any item does not reconcile, do not publish.
The checklist can be shared by marketing, pre-sales, project delivery, legal and customer success. The pass standard is not "the page looks good"; it is that a customer can pick any case and find scope, metric basis, authorisation status, service contact and evidence within 30 minutes, and sales can use the same pack in a technical review.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Scope | Robot/gripper/vision/PLC/safety/logistics boundaries clear | Scope table, interface list | Add boundaries/do not publish |
| Metrics | Cycle time/yield/downtime/ROI have definition, baseline, sample period | Test/acceptance report | Remove numbers/add basis |
| Interfaces/safety | PLC/MES/safety signals/permissions/risk assessment verifiable | Interface docs, risk assessment | Add docs/professional review |
| Customer authorisation | Name/logo/photos/data/testimonial authorised | Authorisation, redaction record | Anonymise/takedown |
| Case evidence | Background/challenge/solution/metrics/timeline/service complete | Case card, project file | Add evidence/remove case |
| Service | Spares/response/training/remote/on-site stated | SLA, spares list | Add service/revise copy |
| Old/expired | Old case/data/logo has takedown record | Takedown record | Takedown/notify customer |
The checklist is an editorial suggestion; technical, safety, customer-authorisation and contract requirements depend on the project/legal advice.
How to handle 90-day updates/old evidence?
Weeks 1–2 inventory cases/authorisations; weeks 3–4 add scope and metric basis; weeks 5–6 add site/service evidence; weeks 7–8 review authorisation/redaction; weeks 9–12 publish and take down old versions.
The page is not finished at launch. Metrics change after delivery, customer authorisation expires, robot/vision/PLC versions update and service policies change. Review case validity, authorisation, metric basis and service promises quarterly; do a full annual review and take down or anonymise cases that are expired, unauthorised or no longer reproducible.
| Phase | Actions | Outputs | Owner |
|---|---|---|---|
| Weeks 0–2 | Inventory cases/customers/authorisations/metrics; decide public/anonymous/customer-audit | Case list, authorisation table | Marketing/legal |
| Weeks 3–4 | Add scope, interfaces, safety, metric basis and baseline | Scope table, metric table | Pre-sales/delivery |
| Weeks 5–6 | Add site photos/video, service/spares/training evidence | Materials, SLA, spares list | Marketing/service |
| Weeks 7–8 | Review authorisation/redaction/personal information/trade secrets | Authorisation, redaction record | Legal/customer |
| Weeks 9–10 | Publish page/case cards; sync sales pack | Page, case cards, sales pack | Marketing/sales |
| Weeks 11–12 | Takedown old versions; data review; next review | Takedown record, review plan | Owner |
The 90-day plan is an editorial suggestion; project, authorisation, metric and publishing cadence depend on the company/customer.
Who should read this, who should not, and what decision does it support?
It fits Changzhou robotics/intelligent-equipment companies building integration-capability pages, case cards and customer audits. It does not fit teams without project/authorisation/metric evidence, or those wanting the page to replace technical agreements or safety assessment.
Who should read: owners, sales, solution/pre-sales, project delivery, marketing and legal at Changzhou robotics/intelligent-equipment companies; teams building an integration-capability page, customer cases, bid materials or customer audits; integrators needing to state cycle time/yield/downtime/ROI and service boundaries. Who should not: teams without project evidence, customer authorisation or metric basis; projects wanting the page to replace technical agreements, safety assessment, CE/acceptance or legal advice; teams wanting to publish customer layouts, processes or unauthorised data. Decisions supported: what to publish and what not, case-card structure, cycle time/yield/downtime basis, delivery boundaries, customer authorisation/redaction, pre-publication acceptance and 90-day updates.
FAQ
What is the difference between an integration-capability page and a customer case page?
A case page answers "who/what have you served"; an integration-capability page answers "can you deliver to my line, interfaces, cycle time and safety requirements". The case page is evidence; the capability page is scope, method, metrics and service. They can link to each other but cannot replace each other.
Without customer authorisation, can we write "an automotive-parts company"?
You can write an anonymised industry/scenario, but ensure the details cannot be reverse-engineered to a specific customer, and state that the customer name is withheld. Customer names, logos, photos, data and testimonials still need authorisation; anonymisation does not permit publishing customer layouts, processes or sensitive data.
How can cycle-time/yield numbers be credible?
State the definition, baseline, measurement boundary, sample period, product/batch, who measured and how anomalies were handled; prefer ranges/indices over a single "30% improvement". Without a baseline or sample period, do not put the number on the public page; you can publish the acceptance basis and offer test records.
What should we watch for in customer-site photos/video?
Customer authorisation, line layout, products/tooling, screens, faces/personal information and trade secrets. Redact/crop/blur before publishing; if uncertain, do not publish or keep it in a customer-audit pack. Personal-information processing follows PIPL; customer trade secrets follow the contract/NDA.
Should an integrator list robot brands/models?
Yes, but do not treat the brand as integration capability. State the brand/model scope, who buys, who commissions, who owns interfaces and safety; if multiple brands are used, explain the selection logic and spares/service capability. Brand authorisation/trademark use also matters.
How should old cases/expired data be handled?
Keep a case ledger: customer/authorisation/metrics/date/version/takedown condition. When authorisation expires, the customer withdraws, the metric basis changes or the project is no longer representative, take it down or anonymise it; update the old page, sales deck and bid materials together.
Bottom line
A Changzhou robotics/intelligent-equipment integration-capability page is not a brand wall: write seven sections—scenario, delivery scope, cycle time/yield/downtime basis, interfaces/safety, customer site, and service. Customer names/photos/data need authorisation and redaction; metrics need a baseline/sample period; accept with scope, metrics, interfaces, safety, authorisation, case and service evidence.
Method and limits
This article is public policy, law and editorial method, not certification, a promise or legal advice for any robot, integrator, project, cycle time/yield/downtime/ROI or customer case. It uses no unpublished customer project, photos, data or contract. The page structure, metric table, boundary table, customer-material table, acceptance checklist and 90-day plan are editorial suggestions; technology, safety, customer authorisation, personal information, trade secrets and contract requirements are governed by project documents, standards, contracts and legal advice.
Sources
Information is current to 30 October 2026; each official/primary page governs its own scope and version.
- MIIT and 16 other departments, "Robot+" Application Action Plan (18 January 2023): miit.gov.cn. Policy context for robotics applications in manufacturing and other scenarios; policy direction is not evidence of any integrator's project results.
- Advertising Law of the People's Republic of China: gov.cn. Boundaries for data, performance and misleading claims in advertising/promotion.
- Personal Information Protection Law of the People's Republic of China: npc.gov.cn. Requirements for customer contacts, employee images and other personal information.