Customer onboarding & support
The takeaway
Make it easier for the customer. Capture the work behind the scenes.
Personal calls and hands-on help are valuable. The bottleneck is collecting information, resolving gaps, reformatting files, documenting interactions and recovering context. A better 3PM experience should reduce that effort without forcing customers into a channel they do not want.
North Star connection: Eddie’s 10,000-asset portfolio target needs less manual work per account—not less care for the customer. The target is not a claim of current capacity.
1. Support: solve the problem without recreating the conversation
What was reported
- Customers often call or email team members directly; some prefer a call over email exchanges.
- Staff troubleshoot, then record categories, actions and resolution notes in a ticket.
- Tickets preserve collective issue history and support later analysis, but recording work adds administration.
- Brendon reported lost access to historical case notes following a deployment. A change was reportedly moving into testing; restoration was not demonstrated.
- Participants were unsure what the AssetPro support entry point currently does. Whether it creates a ticket, opens email or routes elsewhere needs verification.
Ideas explored—not selected solutions
Capture calls, emails and portal requests into a consistent record. Use AI to suggest categories, summarize work and route exceptions. Consider conversational/voice intake while preserving access to trusted people. Give customers acknowledgment and a clear next step.
Questions: Which channels actually carry support volume? What gets recorded today? What can be captured with consent? Who owns acknowledgment, resolution and closure?
2. Onboarding: getting the information is the hard part
What was reported
Customers may return their own files instead of the supplied template. Information can sit with HR, security, training, safety or site management. The person receiving the onboarding request may not have the information or authority to obtain every field.
The team then reviews, follows up, reformats and prepares separate imports. Improving the spreadsheet alone will not solve the customer coordination problem.
Ideas explored
- Pre-populate verified information TLX/PRC already has.
- Accept existing customer data rather than require re-entry.
- Identify an owner for each missing piece.
- Give clear steps and explain why each field matters.
- Prepare the customer during the sales-to-implementation handoff.
- Explore mobile guided intake, scanning or conversational collection. These were options, not approved designs.
Open: incentives were floated, not approved. A completion-rate ambition was discussed; no measured baseline or agreed operational target was established.
3. Departments and shifts: ask for less, without breaking access
Departments and shifts can support reporting and equipment-access restrictions. A machine-shop lift, for example, may need to remain available to an authorized group.
But assignments can change, customers may supply job titles instead of departments, and some customers do not use these reporting dimensions. Actual activity by time of day may be more useful than a stale assigned shift.
Discovery direction: distinguish fields required for access, safety and configuration from optional analytical detail. Explain their value and validate customer-specific needs before making fields mandatory or removing them.
4. Asset data: pre-populate, verify, reconcile
The team described drawing asset information from Creatio, including type, make/model and serial number. Some identifiers were reported as invalid or changed after delivery, preventing retrieval of the correct equipment manuals.
Customers may also lack final asset names or placement until equipment arrives.
Requirements to explore: distinguish manufacturer serial, customer asset name and internal ID; retain provisional values visibly; validate against manufacturer/model context; reconcile after delivery. Do not impose a universal digits-only serial-number rule.
5. Checklists: wording, behavior and device limits
Customers may use asset-specific TLX checklists or their own, including Spanish-language content. Returned templates may omit columns needed to define correct answers and alert/alarm/lockout behavior.
A participant reported a 62-character question limit, including spaces, on the discussed device. Long questions can truncate and lose meaning. Hardware/firmware applicability and character-count behavior still need confirmation.
Near-term ideas: flag overlength content, preview the actual display, obtain customer approval for edits and preserve the intended safety meaning. Do not blindly truncate or silently change failure actions.
A customer also wanted inspection phases such as key-off walk-around → key-on stationary checks → operational checks. This is a structured-guidance need, not merely a request for longer text. Scrolling or richer tablet interfaces remain options to investigate.
6. Imports and the integration opportunity
Participants described separate bulk-import paths for assets, operators, web users and checklists. A multi-tab workbook may require several files and repeated uploads.
The opportunity is to receive what the customer already has, help complete gaps, validate and map it, then prepare or route it to the correct systems. API/MCP approaches were discussed; no integration architecture was approved.
Human review remains important for ambiguous identities, authorization, duplicate records and safety-critical checklist behavior.
7. Usability and testing
The walkthrough surfaced uncertainty about locating support tickets and opening/closing an assistant or chat panel. Automated browser tests were discussed for navigation, buttons and authentication flows.
These are reported usability observations—not reproduced defects or completed fixes.
8. Bring this into Eddie’s journey
| Journey stage | Use cases to investigate |
|---|---|
| Set up | Pre-populate intake; collect data from several owners; validate operators and assets; configure checklists; prepare imports |
| See | Capture incoming support; identify repeat issues and education needs |
| Understand | Retrieve case history; distinguish data errors, configuration gaps, training needs and defects |
| Decide | Determine required fields; review categorization, routing, permissions and checklist actions |
| Coordinate | Reach an available owner; acknowledge the customer; avoid duplicate documentation |
| Prove & plan | Measure effort, completion, resolution quality, repeat contacts and customer outcomes |
This meeting is research input. It does not automatically add product cards, change epic scope or commit delivery dates.
Suggested follow-up—not assigned commitments
| Evidence to bring | What it should reveal | Owner / date |
|---|---|---|
| One real onboarding package: sent → returned → corrected → imported | Missing fields, manual changes, waiting and handoffs | To agree |
| One support interaction: first contact → troubleshooting → record → closure | Channel flow, duplicate work, customer updates and completeness | To agree |
| One checklist: original → configured actions → device display | Required columns, meaning, device limits and safety review | To agree |
| Support entry-point and closed-case access walkthrough | Actual routing, permissions and reproducible behavior | To agree |
Evidence and limitations
Based on the live discussion in this chat and its subsequent summary. Speech was fragmented and some product names, hardware labels, quantities and speaker attributions were unclear. This is a synthesized meeting record, not a verbatim transcript or independent technical verification.
No formal approval of solutions, delivery dates, action ownership or service-level targets was captured. Proposals remain proposals. Customer examples are described generically here; raw conversation and customer files are not published.