For my initial system I'm not building full historical service history, insurance policies, etc. because it's a serious amount of scope on top of the core value prop, which is point-in-time "is this a good quote?". When I eventually do this, I'd need to do it proper with LLM + RAG, etc.
I do have the concept of an "asset" which could be a car, house, etc. and with enough basic info it's pretty easy for the LLM to cross reference common problems, or at least suggest questions that you should follow up on.
I'm leaving intent pretty free-form for now, the most friction I'm willing to add is 2 things:
- Basic enum preferences around budget and flexibility to help with prompting
- A claude code style "a few questions" follow up
Any additional form friction I think gets too complex.
It's funny, a lot of my research has been from subreddits for auto, homeownership, questions for people who work in trades, etc. Every time someone asks "is this quote fair", the response from the experts is almost always "But what do you want"
So in a time-sensitive repairs scenario, intent could "What get's my car safe to drive again for daily commute.... or for a long roadtrip". The output analysis could recommend which fixes are highest priority, where work could be split up, delayed etc.
First, I've spent a ton of time becoming opinionated about a normalized data model that supports the product experience I'm trying to build. This applies both to the extraction (line items, warranty sections, vendors, etc.) and the analysis portion. The latter is imperfect, but aligns philosophically with what I'm willing to stand behind. For example
- building outputs for price fairness (based on publicly available labor data)
- scope match (is vendor over/under scoping user's intent)
I've been working on something like this the last few months specifically around service quote analysis (repairs, construction, hvac, auto, etc.) and it's really cool. I think LLM analysis is the way to go because the amount of complexity is absolutely staggering - just to start the difference in quality and information available on a quote is drastically different between vendors within the SAME vertical. Then to do actual do analysis on local laws, the details of your property (not just photos/videos, but zoning and lot details), vendor analysis, etc.
On top of it all, the most important thing to consider is intent -> An emergency plumbing visit is often very different than a proactive upgrade.
Cool! Another weird thing I've noticed when feature requests are capped for customer teams, is that customer teams will "game" the system.
At scale, customer facing ICs will do things to benefit them personally. It's not a bad thing, it's just human. Sales people do what they need to get quota, Support want to keep their ticket backlog down and CSAT high, etc.
If you receive all customer facing feedback, you can make the final prioritization call on your own. If requests have been filtered too much before they reach you, the priority must be taken with a grain of salt.
As a PM that has started my career in Support/Success... I don't think I could ever advocate a strict two-request limit.
Customers (and customer teams) are a non-stop firehose of feature requests. It's important for the product team to hear all these requests, mostly so they can be understood. It's tedious work, but I do it with the intention of looking for patterns and having a pulse on the customers. You might be surprised by what you find, especially how many feature requests are actually different solutions to 1 larger problem.
My team does this using ProductBoard (https://www.productboard.com/) to synthesize all incoming feature requests on a weekly basis. We sit for 30 minutes as a team to go through direct requests, lost sales opps, etc.. This weekly work pays dividends when it comes time to prioritize features for the next quarter/year, etc.
Customer teams can feel empowered when they are given the tools/opportunity to prioritize things on their own, but the huge downside is that they feel silenced on a large majority of things they can't tell you (i.e. the "lower" priority" requests). This can really eat away at the morale of customer teams that feel they can't share their customer stories with you. When they hear feature requests from customers that they know are low-priority, it feels horrible to tell a customer it won't even be looked at by Product (it's even worse to lie).
I'd recommend a system where all feedback is shared, but only 2-4 feature requests are "voted" for officially by each customer-facing team.
Taking only 'requests' leads to a whole range of potential problems:
- Feature bloat with random one-off buttons and gizmos
- Product teams getting in the habit of ignoring requests if they know that most don't quite fit
- Really complex products (both for customers and internal teams to understand/troubleshoot)
- Unclear roadmaps
- Wasted time. For example, I had a request to build a notification-silencer for specific executives at a company. I recommended that the executive set up email filters instead
My list is too long to share, but let me give you a very simple example.
On most chat platforms, the widget displays an "mail" button or something similar that allows the visitor to send the transcript to themselves for reference later on.
Intercom does not have this, and agents don't the ability to quickly send transcripts either. Our team literally has to copy/paste the transcript into a new Zendesk ticket to send it.
Intercom's philosophy dictates that a 'conversation' is an ongoing thing that happens anywhere: in-app if the user is in session or via email once the user's browser session your website has stopped.
Their philosophy ignores the very clear pattern of visitors treating the intercom widget like a "normal" chat widget (which many have come to expect).
The 2 ways to perceive this are:
- Adding this feature adds value for me and I should pay for it
- Adding this feature bring Intercom to parity with customer expectations, and should be included in the price. Not having it is an unnecessary blocker.
I totally agree with that sentiment, but I find it hard to swallow coming from Intercom.
Even as their customer, I find that they don't like to solve any problem that doesn't fit within their 'philosophy'. I've submitted countless feature requests to no avail, and clearly they've left their customer facing teams high & dry. I feel bad for their support staff and success teams that have been completely disjointed from product teams.
Intercom is my go-to example of a product that tried to re-invent the wheel, but only came up with half of a wheel. They need to finish it. They need to help customers solve the problems they are experiencing, which continue to exist because some missing features don't fit the 'Intercom philosophy'.
Generally speaking for any product team, just make sure you've completed your due diligence of making sure a problem is in fact rare and small. You'll often be surprised at what you uncover.
I would hardly say it's supports job to focus on one thing at at time.
Most people that reach out to support are calling about a specific question or problem. Yes therapy calls do happen. They're not terribly common, but you'll hear about them because they are funny/egregious examples.
When a customer calls about their 1 thing, I can definitely look up the 1 answer or do the 1 fix for them. This is bad support though.
A good support team will listen to that customer, understand what they're needs are and fix that thing while make sure they are set up for success in the future. This means I'm checking different account/user statuses, feature usage, and billing history. I dot his while talking to them, but never letting them know I do this.
If I can understand their 1 question AND know who they are holistically, I can set them up for success and prevent more support tickets down the road.
If you've ever had a user or a profile sent to you in a bad/extreme state, you can bet that a series of 1-off support solutions could have lent to that.
Hi there! Support manager here. I've been leading support teams for years, led support QA teams, built troubleshooting processes and worked very closely with dev teams. A lot of what I wanted to bring up doesn't apply so much to solo dev's, but I want to vouch for non-devs and anyone that might start working on team.
Support brains and developer brains are actually not that different. I see on HN way too often that developers need space and time to think, but other types of people don't. This is myth that needs to be dispelled and everyone should contribute to uphold boundaries that work for everyone.
Trust that absolutely I want you to have 'flow' time - it's important that you both be and feel productive. Good code from you is good code for me and for the user.
What breaks flow is context switching, which is literally baked into the job description for your average support role. Agents often need to answer questions about multiple/complex products, and who knows if they have access to high quality documentation or internal tools.
When something breaks for a customer, agents need to find creative solutions or escalate the issue up do the dev teams. You bet that if there's another call waiting or 20 more emails in the queue, they're not spending a lot of quality time on getting things done right. The bug they submit won't be thorough, and developers won't want to touch those bugs. The workaround they give won't be well explained, and the user won't know how to manage once the call is over. These things wouldn't happen if agents had their 'flow' time too.
I would love to give customers all the time they deserve, but obviously there are limitations to how many agents you can hire to make that happen. When a customer team gets burnout from high support volume, it's rarely the volume alone that makes agents hurt. It's the volume AND context switching. 50 phone calls about different things will leave you a zombie by the end of the day.
It's totally OK that a support person's time is variable like this, but it's dangerous when the pairing developers time is untouchable. Pro tip: make ground rules for what developers might be "on-call" or have office hours, have rotating schedules for which developers need to help support teams, have dedicated places where agents can escalate engineering tasks without physically bothering someone.
Of course, there are so many factors that effect this: how many engineers and support people there are, what kind of issues need to be worked on, what are the priorities for support hours or shipping new code.
At the end of the day, just know that we're all people on one team (albeit with very different daily responsibilities). Respect each other's time and needs, and the rest will fall into place.
You're right, I've seen the type of Orgs in SF where 15-18/hr is the base wage and it's not healthy (for the organization or the people who are working there).
For the most part, I've seen that the type of Orgs with those support wages are likely just trying to throw bodies at support volume. $16/hr for another human to answer X amount of tickets with a Y% satisfaction over Z amount of time. Their customer base is probably B2C or B2B with a large SMB base.
The model is bound to fail, particularly for communication reasons. The type of Org that employs this position is also likely to not have the product feedback loops that connect Support (reactive) with the Product/Eng teams (proactive...hopeuflly). This means product is not addressing bugs quickly or fixing usability issues that support agents frequently work around and explain to frustrated users. It also means they likely don't have adequate internal tooling to solve problems in real-time.
It's a form of technical debt that is REALLY hard to measure - I believe this is because there's too much focus on "standard" support metrics like NPS, FRT, # of touches... Yes these are important, but they are surface level stats for maintaining a basic, "good" support experience. Great support experiences require tighter integration with other teams with better data.
There's no one right answer, but likely a spectrum of options that need to be analyzed for which works best for you.
- Have an international customer base? Maybe outsourcing could be a great option to keep costs low and cover more timezones
- Not interested in outsourcing? Stay in the US and build a new office with talent outside the Bay Area (check out Lyft's Nashville office)
- Do you absolutely need Support to be in HQ? Make the commitment to higher wages and staying lean and effective, not just as a Support team but as 1 company together.
I do have the concept of an "asset" which could be a car, house, etc. and with enough basic info it's pretty easy for the LLM to cross reference common problems, or at least suggest questions that you should follow up on.
I'm leaving intent pretty free-form for now, the most friction I'm willing to add is 2 things:
- Basic enum preferences around budget and flexibility to help with prompting
- A claude code style "a few questions" follow up
Any additional form friction I think gets too complex.
It's funny, a lot of my research has been from subreddits for auto, homeownership, questions for people who work in trades, etc. Every time someone asks "is this quote fair", the response from the experts is almost always "But what do you want"
So in a time-sensitive repairs scenario, intent could "What get's my car safe to drive again for daily commute.... or for a long roadtrip". The output analysis could recommend which fixes are highest priority, where work could be split up, delayed etc.