Staff, fleet and guest charging: agree the permission rules before buying

1. Separate three decisions that are often mixed together

First decide whether a person or organisation is entitled to request charging. Then decide how a permitted session is priced or allocated to a cost centre. Separately decide whether the vehicle is allowed to enter or occupy a parking space. A gate pass, a recognised charging credential and a payment receipt are not interchangeable evidence.

The Open Charge Alliance FAQ describes OCPP as communication between charging stations and management systems, and notes that implemented functionality depends on the station and backend. For procurement, ask for the exact model, firmware, backend version and supported authentication methods. Do not treat the protocol name as proof of your site's complete permission workflow.

• Eligibility: the user group, permitted equipment and validity conditions.
• Commercial treatment: the agreed tariff, employer allocation or other accounting rule.
• Site access: parking, booking and physical-entry arrangements managed by the site owner.

Use the billing-reconciliation guide for session-to-charge evidence. This article concentrates on eligibility, not tax treatment or payment-network approval.

2. Write one permission matrix in plain language

List the groups that genuinely need different rules. Avoid creating a separate group for every individual unless the operating model requires it. Keep the business rule understandable before asking a software provider to translate it into configuration.

These rows are illustrative, not a product feature list. If the chosen system cannot express a rule, record the gap before ordering. Agree a simpler operating policy or a supported alternative; do not quietly replace a controlled guest policy with unrestricted access.

3. Define the lifecycle, not just the first successful start

Identify who requests, approves, issues, changes and withdraws each permission. A lost credential, a departing employee, a reassigned vehicle and a visitor who stays longer than expected are distinct cases. Give each case an owner and an auditable resolution.

1. Issue: verify the approved request, scope and start/end conditions through the site's normal process.
2. Change: record the reason, old scope, new scope and authorised approver.
3. Expire or revoke: agree when new charging requests must stop being accepted and how completion is evidenced.
4. Review: decide who checks unused or inappropriate permissions and how often, according to the site's own policy.

Specify the effect on new requests separately from the effect on a session already in progress. Do not assume that changing a dashboard record instantly changes every station or ends an active session. Ask the providers to document their supported behaviour, delivery acknowledgements and exceptions.

Where time windows are required, identify the authoritative time zone, clock source and applicable local clock-change handling. Test a boundary with authorised test data; never change production clocks merely to make a demonstration convenient.

4. Include offline and delayed-update cases in the contract

A business rule should state the desired outcome when the management platform cannot be reached, while the technical proposal explains what the selected equipment actually supports. Ask whether any local authorization data is used, who maintains it, how changes reach the equipment and how the operator identifies a pending update. Do not assume that an online revocation is already effective on disconnected equipment.

Have the supplier identify unsupported combinations and the owner's approved contingency. The goal is a documented decision, not a universal recommendation to allow or deny every offline request. Read the offline-operation procurement checklist alongside this policy. Simulated connectivity changes belong in an approved pilot plan, not an unscheduled interruption of a live site.

5. Accept both permitted and denied requests

A demonstration that one staff card starts one charger is incomplete evidence for a mixed-user site. Build a short test list from the permission matrix and record the expected result before testing. Use designated accounts and the exact intended hardware/software combination.

• A valid test user requests its assigned charger.
• The same test user requests equipment outside its agreed group.
• A not-yet-valid or expired test guest requests a session.
• A revoked test credential is presented after the agreed update has been delivered.
• A planned permission change is checked against the documented active-session behaviour.
• An approved offline scenario is reviewed against the agreed contingency and recovery process.

For each case retain a test reference, permission-policy revision, station/output reference, timestamp with time zone, expected result, observed result and reviewer. Link only sanitised evidence. A failed test is an open acceptance item, not a reason to modify the expected outcome afterwards.

Keep card secrets, tokens, passwords, personal identifiers and unrestricted user lists out of shared sales or support records. Agree data access, retention and local privacy obligations with the responsible qualified teams. The asset-register guide helps prevent evidence being attached to the wrong station.

6. Price the administrative work as well as the equipment

Ask which party configures the first groups, imports approved users, trains administrators, handles later changes and exports the accepted policy and evidence. Separate included setup from recurring account fees, integrations and manual support work. Request the software provider's actual limits on groups, sites, users and supported methods instead of assuming that a hardware quotation includes unlimited administration.

For example, a fictional office depot could propose staff access on workplace AC equipment, a separately approved fleet group and sponsored guest access on a selected charger. Before selecting that arrangement, the buyer must establish equipment availability, departure needs and the supported permission rules. Permission to charge does not reserve power or guarantee that a vehicle reaches its departure energy target.

Use the free RFQ builder to organise the project brief and attach the permission matrix as an additional requirement. The planning tool does not approve the policy or implement access controls.

Keep AC and DC cooperation tracks explicit

AC EV charger SKD kits and technical documentation: confirm the selected AC model, supplied components, supported access interface, assembly document revisions and the agreed backend integration and acceptance responsibilities.

DC EV charger SKD kits and technical documentation: confirm the selected DC configuration, component and software-interface scope, output mapping and project-specific integration, testing and maintenance responsibilities.

Xiaochong recruits businesses interested in local charger production or assembly. SKD components, production/assembly technical support and professional repair/maintenance support can be scoped to the project. Available AC or DC technical documentation is free on request. Hardware, training services, repair labour, unrestricted software/IP rights and certification are not automatically free or included. Agree exact models, document revisions, languages, licences and deliverables in writing.

Buyer questions

Does an RFID reader prove that a charger supports our access policy?

No. Ask the charger and backend suppliers to demonstrate the selected user groups, station permissions, expiry and revocation rules on the agreed hardware and software configuration.

Is charging permission the same as a tariff or parking permission?

No. Define charging eligibility, price or cost allocation, and physical parking access separately. Confirm how the selected systems connect these decisions without assuming that one approval grants the others.

What should happen when a staff member leaves or a guest pass expires?

Assign an owner to revoke or expire the permission and verify the agreed outcome for new requests. Separately define handling of sessions already in progress and any offline data, using the approved system procedures.

Request an AC or DC access-policy review

Send your country, company, AC or DC track, site and pilot quantities, user groups, intended backend and required document language. Ask for free available AC or DC technical documents and confirm which permission requirements the proposed configuration can demonstrate.

Review the official partner programme, AC/DC SKD technical-output page and procurement guide. Documents remain subject to approved sharing; no private factory file is published here.

xc0225888@163.com · Sales 1: +86 137 1772 6888 · Sales 2: +86 134 2580 6997