Support
Academy first, then humans who can open the same products you run. We use Desk ourselves.
Support model
We run Desk ourselves. Support staff can open the same product family you run. That is intentional: tickets without product context create heroics and wrong fixes.
Start with Academy and in-app help when the issue is work design. Open support when the account is blocked, the product misbehaves, or you need an owner on a severity path.
If a partner implements your estate, start with that partner for delivery issues. CEDX supports platform contracts and account administration; delivery partners own configuration they shipped unless the joint plan says otherwise.
What to include in a ticket
Name who is blocked and since when. List products, region, and a reproduction path. Say what you already tried so we do not loop. Attach screenshots from the live app, not from an old deck.
Severity is about business impact, not volume of email. Breach risk and finance close windows escalate differently than a cosmetic UI question.
Model
We run Desk ourselves so support staff can open the product family you run instead of guessing from screenshots alone. Work-design issues start in Academy; account and product defects go to Support; delivery config goes to the implementing partner when one owns the SOW.
Ticket quality needs impact, estate context, reproduction, already tried, and live-app screenshots. Severity is business impact, not email volume; breach risk and close windows escalate differently than cosmetic UI.
Named ownership on high severity continues until clear with status in-thread rather than tribal chat only. Post-incident actions are written and product fixes are tracked so the same failure does not recur quietly.
Public high-level incident notes may appear in News; enterprise status hooks depend on plan. Security issues use responsible disclosure via contact — do not post exploit detail publicly first.
Routing
Platform defects and account administration: CEDX Support. Configuration delivered under a partner SOW: partner first, escalate with joint context when platform behavior is suspected.
Enablement and co-sell operations: partner success queues by tier. Work design and queue design: Academy and quick reads before tickets.
Hobby production debugging is out of scope; Support is for customers and partners on the estate. If you are evaluating, use contact for estate map rather than severity tickets on demo data.
Always include products, region, and timing so routing is correct the first time. Duplicate threads across email, chat, and tickets slow response; pick a primary channel and reference it.
What good looks like
Response targets follow severity; communicate impact honestly so prioritization matches reality. Ownership is named on high severity until clear, including handoffs across time zones when needed.
Comms stay in-thread with decisions written so new participants do not restart discovery. Workarounds are labeled as temporary and tied to fix tracking when product change is required.
Customers and partners who provide clean reproduction save days; incomplete tickets bounce. We will ask for missing context rather than guessing wrong and shipping a harmful change.
If you disagree with a resolution, escalate with new evidence rather than reopening without content. Partner tier queues change enablement speed, not the laws of physics on complex multi-product estates.
Prevention
Pilots with written metrics and retire lists produce fewer emergency tickets after go-live. Academy modules before config reduce work-design incidents that look like product bugs.
Identity and entitlement design done early prevents access chaos that floods Support later. Sandbox proof for extensions prevents production surprises that page the wrong team.
Hypercare exit criteria stop infinite soft-launch limbo where every issue is severity one. Named BAU owners after hypercare keep knowledge from walking out with the project team.
Use monitoring and desk wallboards so breach risk is visible before the customer feels it. That is how we staff and how we recommend you staff — see the Support lifestyle band and Desk product pages.
Severity examples
High severity includes widespread login failure, data loss risk, payment or close-path outages during critical windows, and security incidents with active exploitation risk. Cosmetic UI issues and single-user preference questions are not high severity no matter how loudly they are emailed.
If a partner misconfiguration blocks a customer, say so in the ticket so routing includes the implementer instead of only platform engineers. Honest routing is faster than polite misdirection.
Provide timestamps, product names, regions, user role, and whether sandbox or production is affected. Missing environment context wastes the first hour of response.
If you have a workaround, state it; if you do not, say you do not — false workarounds create secondary incidents. We would rather know the blast radius than inherit a fantasy.
Security disclosures should go through the responsible path via contact with enough detail to reproduce without publishing exploit steps to the world. Public exploit posts first will not get you faster fixes; they get you a worse day.
Partner-led delivery support
When a partner implements, they are first-line for configuration and training issues under their SOW. CEDX is first-line for platform defects and account administration; joint escalation exists when the boundary is unclear.
Open joint tickets with both partner and customer contacts when the issue might be either side. Serial tickets that hide the partner slow root cause.
Partners should not promise platform changes as delivery scope; that creates commitments CEDX Support cannot honor on a services timeline. Use product feedback paths for enhancements; use Support for defects.
Tier queues change partner enablement responsiveness; they do not invent new laws of complex multi-product debugging. Clean reproduction still wins.
After major incidents on partner-led estates, write a short shared post-incident note: cause, fix, prevention, owner. Without that note, the same failure returns next quarter.
Self-serve that actually helps
Many tickets are work-design problems: stage definitions, job fields left blank, close cutoffs ignored, inventory promises without cycle counts. Academy modules exist specifically for those problems; use them before assuming the product is broken.
In-app help is context-aware where shipped; start there when you are mid-flow rather than context-switching to email. Screenshots of the live app beat descriptions that omit the product surface.
Quick reads are for single-habit fixes between meetings; full tracks are for pilot-shaped change. Pick the depth that matches the decision you need this week.
If self-serve fails, your ticket should say what you tried so Support does not loop you through the same steps. That courtesy is also self-interest — it shortens time to a real answer.
Champions should teach operators the self-serve path during hypercare so BAU does not depend on a single hero who knows how to open a ticket well. Hero culture is not a support strategy.
After go-live
Hypercare exit means metrics are trusted, owners are named, and the war room calendar can die. If the war room is still weekly six months later, the program did not exit — it renamed itself.
BAU support paths should be documented for new hires: Academy links, in-app help, partner contact, CEDX Support criteria. Undocumented paths recreate tribal knowledge.
Review access quarterly; identity sprawl after go-live is a common source of both security and support load. Entitlement reviews are cheaper than incident response.
Product upgrades and new estate products should go through a mini estate map: metrics, owners, training, retire list updates. Drive-by admin changes are how stable estates become fragile again.
When you expand to a new region or entity, treat it as a wave with acceptance tests, not as a checkbox in a tenant setting. Multi-entity mistakes are expensive to unwind.
Get unblocked
Practical detail for operators, partners, and builders evaluating the estate.
Design the work before you open a ticket.
Context-aware where shipped.
Account and technical issues.
If a partner implements you, start there.
Severity mindset
Practical detail for operators, partners, and builders evaluating the estate.
Who is blocked, since when.
Products, region, repro.
So we do not loop.
Channels
Context-aware help where shipped.
Account and technical issues.
Delivery issues start with implementer.
Work-design issues before tickets.
Incident high-level notes when public.
Responsible disclosure path via contact.
Plans & expectations
Severity-based — impact first.
Named on high severity until clear.
Status in-thread, not tribal Slack only.
Actions written; product fixes tracked.
On the queue
Breach risk visible before the customer feels it.
FAQ
Straight answers before you book time or open a ticket.
Incidents summarized under News; enterprise status hooks on plan.
Support is for customers and partners on the estate.
Start with the implementer for delivery issues; CEDX owns platform contracts.
Use contact with responsible disclosure context — do not post publicly first.
Open a live product, book an estate map, or join the partner program.
