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, its subsequent summary, and Scott Wayman’s October 16 “Product Discovery Meeting” email to Katie Vo. 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.
Next steps — Scott’s follow-up
Two PRD workstreams: support and onboarding. Preserve the white-glove experience while removing manual work that will not scale. Carry the underlying problems into PRDs, linked development cards, product/engineering review and a capability-level roadmap—not disconnected features.
For review—not nine approved roadmap commitments. Implementation owners, delivery dates and roadmap sequence were not settled by the meeting or this email.
What the email clarifies
- Scott records a working estimate of roughly 40% system / 60% calls, texts or email for Brandon’s requests; Tyler described calls/email. These are estimates, not measured baselines.
- Documenting and closing a case can take about as long as fixing it, depending on the issue. Keep history and categorization; remove duplicate administration, not visibility.
- Complete information collection is the onboarding choke point affecting shipment; converting files is only part of the work.
- Customer examples reinforce identity conflicts, removed checklist fields, a reported 62-character display constraint and serial-number uncertainty. An integration alone does not fix bad identifiers.
Nine candidate building blocks
1. Channel-independent support capture
Turn calls, emails and other interactions into a traceable case without requiring the customer or support representative to re-enter the conversation.
Proof to seek: The issue, customer, response and resolution history survive the handoff, and the customer knows someone owns it.
2. Support classification and routing
Distinguish education, hardware, RMA, reporting and other requests, then direct them to the correct owner.
Proof to seek: Test against real historical cases with human correction and escalation; do not assume a fully autonomous agent.
3. Guided onboarding orchestration
Establish company/site context, show the next required step and help the customer identify who holds missing information.
Proof to seek: A real account can finish prerequisites without repeated spreadsheet chasing. Measure completion, elapsed time and staff effort. Mobile links and voice agents are interface options—not the requirement.
4. Source-to-template transformation
Accept existing customer material and map it into the separate operator, web-user, asset and checklist structures AssetPro requires.
Proof to seek: Replay real examples without manual copying between templates; flag unmapped fields before upload.
5. Identity reconciliation
Surface duplicate operators, conflicting badges, uncertain asset names and questionable serial numbers for confirmation.
Proof to seek: Catch conflicts without silently selecting an identity; check manufacturer-specific serial formats rather than imposing a universal length.
6. Conditional configuration and access rules
Ask for shift and department detail when it supports the customer’s reporting or equipment-access needs, and explain why.
Proof to seek: Simplifying onboarding must not broaden equipment access. Static shift assignments were challenged as an analytics proxy; the fields can still govern who may operate assets.
7. Checklist semantics
Preserve questions, answer choices, expected responses and failure actions for the relevant asset type; support customer wording and generic templates.
Proof to seek: Incomplete submissions must not silently produce incorrect alert or lockout behavior.
8. Device-aware checklist presentation
Validate content against the actual unit’s display constraints before it reaches an operator.
Proof to seek: Flag and review overlength questions without losing safety meaning. Confirm whether the reported limit is hardware/firmware-related and whether scrolling is feasible.
9. Validated cross-system handoff
Reuse known asset information across Creatio, the 3PM experience and AssetPro, then confirm the resulting records.
Proof to seek: Verify that data reaches the right site and assets, and expose failures rather than reporting success from an attempted upload. MCP is a possible route—not a settled architecture.
How Scott recommends carrying this forward
Use the building blocks as linked requirement sections and explicit dependencies within the two PRD workstreams.
Roadmap capability headings: scalable support; guided onboarding; reliable data ingestion and identity; configurable inspections; validated system handoffs.
Clarify hardware/firmware boundaries alongside software and 3PM for device presentation. Do not assume the solution is a software rewrite.
Evidence needed next
- A couple of before/after onboarding examples.
- Support-ticket export and actual volume/category baseline.
- Persona and data-owner map; confirm which fields are truly required.
- Confirmation of the device-display constraint.
The email records a near-term form experiment, further research and another huddle next week. Exact dates, implementation owners and approved delivery scope remain unconfirmed.