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. franklinwh). A full list is available in the Texture Docs.


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 referenceId convention — 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

referenceId

Customer's account number — join key back to your system of record

firstName / lastName

Becomes the Contact record

streetOne, city, state

Becomes the Site record

systemIdentifier

Device serial number — used for device binding

manufacturerSlugs

Exact OEM slug (e.g. franklinwh) — selects the integration

programSlug

Auto-enrolls the device into the program

tags

Optional

Fleet groupings (e.g. residential, cohort-2, lmi)

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.