Utility & Co-op Program Implementation Guide
Last updated: June 3, 2026
This guide walks you through onboarding your DER program onto the Texture platform — from kickoff through launch. Use it to understand what to expect at each phase and what you'll need to have ready.
Key concepts
Term | What it is |
|---|---|
Program | The container your devices auto-enroll into during bulk import. |
Event Stategy | Dispatch configuration (event types, target SoC ranges, ramp behavior). |
Site | The physical address record. Carries map, weather, and a linked contact. |
Contact | The customer/account record (name, email, phone, reference ID). |
Device | The device record. Streams live status: state of charge, power, device state, and other telemetry (varies by device type). |
Registered System | A device that's been imported and is known to the platform, but is not yet bound to an OEM account — not yet dispatchable. |
Device on Workspace | A Registered System becomes a Device on Workspace once the platform can reach it via the OEM's API. At this point it streams telemetry and is dispatch-eligible. |
referenceId | A unique identifier for each customer — typically their utility account number. This is the join key back to your system of record. |
systemIdentifier | The device serial number (e.g. aGate serial, Tesla DIN, Emporia serial number) used for device discovery. |
manufacturerSlug | The exact OEM identifier used to tell Texture which integration to wire up (e.g. |
Implementation timeline at a glance
Phase | Typical window | What happens |
|---|---|---|
Kickoff & prerequisites | Week 0 | Data scope agreed, OEMs confirmed |
Bulk import | Week 1–2 | Sites, Contacts, and Devices created on platform |
Device Discovery | Ongoing | Devices provision and begin reporting telemetry |
Testing period | Until launch − 2–4 weeks | Dispatch validated end-to-end |
Training | Once live data exists | Your team trained on real fleet data |
Launch | Launch day | Production dispatch enabled; support model in place |
Phase 0 — Kickoff & prerequisites
What Texture needs from you:
Confirm the program type (Battery, EVSE, EV, etc.), OEM(s), and approximate device count
Identify your
referenceIdconvention — typically your utility account number format. Texture will advise on best practices if needed.Share your data scope: the goal is to get at least some devices on platform as quickly as possible. Texture will walk you through what the Bulk Import tool expects and what a successful import looks like.
Identify your points of contact for: program manager, technical lead (if applicable), project team
What Texture does:
Verifies all OEMs in scope are supported integrations
Agrees on target launch window and back-plans testing and training dates
Exit: Data scope and OEM(s) confirmed; key contacts and target launch date agreed.
Phase 1 — Program setup
Texture will create and configure your program on the platform. During this phase:
Your program gets a unique slug (e.g.
timber-ridge-2026-vpp)You'll confirm enrollment requirements — which customers or devices qualify, and whether approvals are automatic or manual
If it's a VPP program, Texture will demonstrate how events can be scheduled, customized, and automated, and show you the Program Event Reports you'll use to evaluate dispatch performance
Exit: Program is live with dispatch configuration confirmed.
Phase 2 — Bulk import
This step loads your customer, site, and device data onto the platform.
What you provide:
A CSV with the following fields for each device in scope:
Field | Required | Description |
|---|---|---|
| ✅ | Customer's account number — join key back to your system of record |
| ✅ | Becomes the Contact record |
| ✅ | Becomes the Site record |
| ✅ | Device serial number — used for device binding |
| ✅ | Exact OEM slug (e.g. |
| ✅ | Auto-enrolls the device into the program |
| Optional | Fleet groupings (e.g. |
Texture can run the import or guide your team through it. After import, each row becomes linked Site + Contact + Device records in the platform.
What to expect: Devices will initially appear as Registered Systems — this is normal. They'll remain in this state until device discovery is complete (Phase 3).
Exit: Sites, Contacts, and Devices created and correctly linked; devices visible as Registered Systems.
Phase 3 — Device Discovery
This is the step that unlocks everything downstream: telemetry, dispatch, and program participation. A device moves from Registered System to Device on Workspace once the platform can reach it via the OEM's API.
What needs to happen (varies by OEM):
Batteries (e.g. FranklinWH): Device is installed and commissioned; OEM integration is configured in Texture (FranklinWH cp/ck keys set up, integration tile enabled)
Batteries (Tesla): Tesla PowerHub instance provisioned and connected; if the program involves grid services, ensure virtual key pairing is complete
EVSE (e.g. Emporia, ChargePoint): Customer has an active OEM account that devices can be provisioned to; integration wired to your workspace
EVs: OEM is supported (directly or via Smartcar); each driver connects via a Texture Connect Session to authorize data access
Device provisioning happens device-by-device as units come online. This phase runs continuously as more devices are added to the program.
Exit: A meaningful portion of the fleet is reporting telemetry and dispatch-eligible.
Phase 4 — Testing period
Before any real dispatch, Texture will run controlled test events to validate the end-to-end flow. No production dispatch happens during this phase.
What gets validated:
Dispatch command roundtrip (discharge, charge, idle)
SoC and power telemetry arriving at expected cadence
Scheduled events running end-to-end without intervention
Recovery behavior after a dropped connection
In-platform reports compiling correctly
If you need custom reports beyond Texture's native reporting, share your requirements and delivery cadence during this phase.
Exit: Dispatch validated end-to-end and signed off.
Phase 5 — Training
Training sessions are role-shaped so each part of your team learns what's relevant to them. Texture schedules training once live devices are reporting — so sessions use your real fleet data, not hypothetical examples.
Role | Focus |
|---|---|
Ops | Alerts, dispatch monitoring — filtering the fleet, reading event timelines, drilling into a device |
Customer Support | Site lookup & first-line troubleshooting — finding a customer by account number, checking device status, understanding Registered System and offline states |
Engineering | API access & programmatic data pulls — token setup, endpoints, rate limits, webhook conventions |
Program Leads | KPIs & program performance — program rollups, dispatch history, energy delivered, opt-out trends |
Exit: Each relevant role trained on live data.
Phase 6 — Launch
Enrolled-device count meets the launch threshold
Test sign-off and training complete
Production dispatch enabled
First production event(s) execute and report correctly
Ongoing support cadence and escalation path confirmed
Post-launch check-in scheduled
Exit: Program dispatching in production; support model in place.
Device states reference
State | What it means |
|---|---|
Registered System | Imported and known to the platform, but not yet bound — not dispatchable. |
Device on Workspace | Telemetry streaming; visible in fleet and program rollups; dispatch-eligible. |
Offline | Previously live, not currently reporting — check network and OEM connectivity. |
Have questions? Contact your Texture implementation team or reach out via your shared Slack channel.