First 90 DaysBuilding Scalable Support at FieldStack

Individual 1-on-1s: Understanding Management Preferences

Approach: Ask each team member:

• How do you like to be managed? (Visual learner? Hands-off? Detail-oriented?)
• Is your current preference working for you or is it a hindrance?
• What would make your job easier?

Purpose:

• Learn how each person works best
• Begin positioning them as future leaders (when team scales, need leads from within)
• Identify who has leadership potential vs. who wants to stay technical

Output: Individual relationships, understanding of team dynamics, development baseline

Workflow Documentation Exercise

Approach: Ask each analyst to document their current workflow:

• How do you handle a ticket from start to finish?
• What works for you? What works against you? Why?
• Where do you get stuck or frustrated?

Purpose:

• Extract existing tribal knowledge before it's lost
• Map overlaps across individual approaches to find common ground
• Build standardized baseline FROM their processes, not imposing external system
• Create buy-in through participation (can't argue with their own documented processes)

Output: Workflow documentation that becomes foundation for standardization

Shadow & Learn

• Spend time with each agent observing their work
• Take genuine notes, ask questions, learn the product
• Shows respect: "You know this better than I do - teach me"

Output: Understanding of current workflows, pain points, tribal knowledge

Go Through New Employee Training

• Experience what new agents experience
• Identify gaps, outdated info, unclear processes
• Demonstrates humility and willingness to start from baseline

Output: Baseline product understanding + training improvement opportunities

Attend Client Calls / Review Tickets

• See customer perspective firsthand
• Understand common issues, tone, expectations

Output: Customer empathy, issue pattern recognition

Fix Obvious Broken Processes

• Things everyone complains about but "that's just how we do it"
• Low-effort, high-impact changes
• Demonstrates execution capability and builds immediate credibility

Output: Team trust, proof of follow-through

Establish Clear Escalation Paths

Current state: No formal escalation path; customers prefer specific analysts

The problem:

• Support analysts maintaining personal client relationships (that's Account Management's job)
• No coverage when expert analyst is unavailable
• Clients treating analysts as "their person" creates dependency and burnout

The fix:

• Build routing based on issue type, not customer preference
• Establish coverage matrix (if Expert 1 is out, Expert 2 covers)
• Define decision tree: When to handle independently vs. escalate

Re-education needed:

• Customers: Your support contact is the TEAM, not Bob specifically
• Analysts: Your job is solving problems, not maintaining relationships (that's Account Management's role)
• Account Management: You own client relationships, Support owns problem resolution

Why this matters: Prevents customer dependency on individual analysts, enables vacation/coverage, reduces burnout

Output: Clear escalation procedures, reduced bottlenecks, agent empowerment

Rotating Responsibility: Ticket Coordinator (Weekly)

Purpose: Give everyone exposure to triage and routing decisions

Responsibilities:

• Review incoming tickets
• Assign based on expertise + workload balance
• Decide Tier 1 (analyst handles) vs. Tier 2 (needs coordination/escalation)
• Monitor for tickets falling through cracks
• Report patterns at weekly team meeting

Rotation mechanics:

• Ask for volunteer for first rotation (sets standard)
• Then alphabetical order ongoing
• Rotation is mandatory part of role
• Remains consistent until team size necessitates evolution

Why rotation works:

• Prevents "that's not my job" mentality
• Builds empathy ("coordinating tickets is harder than I thought")
• Everyone shares accountability for team outcomes
• Surfaces who's good at what (and who wants to avoid what)

Output: Distributed ownership, skill development, identification of future specialists

Weekly Team Meeting Cadence

• Communication and pattern-sharing, not status reports
• Share wins, discuss trends, surface blockers
• Team-owned time for collaboration

Output: Team cohesion, shared awareness, proactive problem-solving

Support Matrix as Marketing Asset

Opportunity: Position support as competitive differentiator

Customer-facing support matrix:

• What we support
• Response time standards
• Expertise areas
• How to get help effectively

Why this matters:

• Sales tool: "Look how organized our support is"
• Customer expectation management: Clear standards prevent surprises
• Competitive differentiator: "Other platforms have terrible support - here's proof ours is world-class"

Support becomes revenue driver: When sales can point to support quality as reason to buy, support stops being cost center and becomes strategic asset.

Collaborate with: Marketing to position this as sales/retention tool

Output: Support visibility, competitive positioning, clear customer expectations

Process Documentation (SOPs)

• How we handle common scenarios
• Written BY the agents who do the work
• Captures team expertise for scaling

Output: Onboarding resource, consistency tool, scaling foundation

Knowledge Base - Internal

• Troubleshooting guides and product quirks
• Preserves collective team knowledge

Output: Faster training, reduced tribal knowledge dependency

Rotating Responsibility: Knowledge Base Curator (Weekly or Bi-Weekly)

Purpose: Give everyone exposure to documentation and knowledge management

Responsibilities:

• Review KB articles for accuracy
• Identify gaps (what questions come up that aren't documented?)
• Work with analysts to create new articles
• Archive outdated content
• Report on KB usage and effectiveness

Why this rotation with Ticket Coordinator:

• Tickets = reactive work (handling what comes in)
• KB = proactive work (preventing tickets from happening)
• Together they define support operations: respond well + reduce volume

Output: Living documentation, distributed ownership of knowledge management

Knowledge Base - Customer Facing

• Self-service for common issues
• Reduces inbound ticket volume
• Answers common questions once, scales infinitely

Output: Volume reduction, better customer experience, analysts freed for complex work

Review Existing Instructional Assets

Context: Sales rep previously created instructional videos for clients

Questions to answer:

• Are they useful for support purposes?
• Are they sales-focused or support-focused?
• Too technical? Too basic? Outdated?
• Can they be repurposed for KB or should we start fresh?

Cultural note: FieldStack doesn't upsell - new features are free to existing clients. Support content should reflect this partnership approach.

Output: Understanding of existing assets, plan for reuse or retirement

Ticket Categorization System

• Standardized tagging for issue types
• Enables pattern recognition and data analysis
• Foundation for meaningful metrics

Output: Data foundation for metrics

Ticket Lifecycle Clarity

Current state assessment needed:

• What ticket statuses exist now?
• How do analysts currently track progress?
• What closure process exists (if any)?
• Where are the pain points?

Goal: Define clear ticket lifecycle

• Statuses: New, In Progress, Pending Client, Resolved, Closed
• Closure reasons: Resolved, No Response, Duplicate, Out of Scope, etc.
• Automated reminders: If pending client >7 days, nudge them
• Clear ownership: Who's responsible for next action at each stage

Why this matters:

• Can't have meaningful metrics without clean data
• "Old ticket" problem solves itself with proper lifecycle tracking
• Pattern analysis requires consistent categorization

Output: Clean data foundation, proper ticket hygiene

Address Duplicate Ticket Problem

Current issue: Large clients submit 5 tickets from 5 people about same issue

Technical fix:

• Tagging system flags potential duplicates
• Parent/child ticket relationships (5 child tickets → 1 parent issue)
• Dashboard showing active issues (visibility: is someone already working this?)

Client education fix:

For NEW clients (during onboarding):

• "Here's how to submit tickets effectively"
• "Designate a support coordinator who checks with team first"
• Build into sales/onboarding process

For EXISTING clients (gentle transition):

• "We're evolving our support process to serve you better"
• "To improve response times, please designate a support point person"
• Frame as UPGRADE, not restriction

Why this matters: Prevents wasted analyst time, improves response efficiency, manages client expectations

Output: Deduplication system, client education process

Define Metrics That Matter

Not just "tickets closed" - metrics that help the TEAM, not just management reporting

Core operational metrics:

• Response time (how fast do we acknowledge?)
• Resolution time (how long to actually solve?)
• First contact resolution rate (solved without escalation?)
• CSAT/NPS (what do clients think?)
• Escalation rate (how often do we need help?)
• Ticket volume trends (what's driving demand?)

Strategic metrics:

• Top 10 ticket drivers (where's the pain?)
• Time-to-competency for new hires (how fast can we onboard?)
• Agent utilization (balanced workload or burnout risk?)

Key positioning: "These metrics help US work smarter, not micromanagement surveillance"

Output: Shared understanding of success

Simple Metrics Dashboard

• Make performance visible to team
• Focus on trends and patterns, not just daily numbers
• Demonstrates team impact and enables data-driven decisions

Output: Transparency, informed decision-making

Identify Top 10 Ticket Drivers

• What's causing the most volume?
• Which can be prevented vs. just handled better?
• Work smarter through root cause analysis

Output: Root cause insights, product feedback for engineering

Proactive Client Communication for Large Accounts

Context: JR mentioned that a large client audits still-open tickets at year-end to evaluate support value

Challenge:

• Reactive year-end review creates fire drill
• No ongoing visibility into ticket status throughout year
• Support appears reactive rather than proactive

Solution: Proactive Monthly Reporting

• Monthly summary: "Here's what we resolved, here's what's still open and why"
• Clear ticket status definitions: "Open" vs "Pending your response" vs "Monitoring"
• Regular check-ins prevent year-end surprises

Strategic benefit:

• Transforms support from reactive to proactive partner
• Demonstrates ongoing value throughout year, not just at audit time
• Positions support as strategic resource, not just ticket handler
• Use as model for other enterprise client relationships

Output: Proactive client communication framework, improved enterprise client relationships

Data Access & Governance (Future Consideration)

SQL and database work came up multiple times in interviews. Once foundational support processes are solid (ticket lifecycle, metrics, documentation), exploring support's access to customer data becomes a strategic opportunity.

Questions to address:

• What customer data does support need vs. what creates liability?
• How do we protect the support team if broader governance frameworks are unclear?
• What department-level controls can support implement?

This is a post-90-day project that warrants its own strategic planning. See Appendix A: Data Access & Support Team Liability

Training Infrastructure (Not Training Department... Yet)

The unsaid foundation: Building toward a training function they don't know they need yet

Phase 1 (Now - 10 employees):

• Knowledge base = self-service training
• Analysts contribute content asynchronously
• No expectation that analysts "also do training"

Phase 2 (10-20 employees):

• Training modules + shadowing program
• Identify "Training Analysts" through voluntary interest
• Senior analysts mentor new hires (paid, recognized responsibility)
• Dashboard data becomes training metrics

Phase 3 (20+ employees):

• Dedicated training role/department
• Built on foundation of documented processes, modules, metrics
• Analysts freed up to do actual support work

Why this approach:

• You're not asking current analysts to "also train" (that's bullshit and they'd resent it)
• Building infrastructure NOW that becomes training department LATER
• When growth demands it, foundation already exists

The sell to team:

"We're capturing your expertise now so when we grow, you're not constantly training every new person. You do it once, we systematize it, future-you thanks current-you."

Training Analyst Role (Phase 2)

When team hits 10-15 people:

The ask:

"As we grow, we need people who can mentor new hires. This comes with more responsibility - training coordination, shadowing, documentation work. It also comes with recognition and compensation adjustment. Who's interested?"

What this does:

• Self-selection = 100% buy-in
• Frames as opportunity, not promotion
• Transparency about scope and compensation

Titles that aren't hierarchical bullshit:

• "Training Analyst" (you train analysts)
• "Lead Analyst" (you lead initiatives, not people)
• "Specialist" (you specialize in X domain)

Avoid: "Senior," "Manager," "Supervisor" (all imply hierarchy)

Why tell them once:

"We're building training infrastructure because we're growing. I need people who can help new hires ramp fast so YOU aren't constantly interrupted. This role makes your job easier long-term."

If they argue with the why, that's fine. They don't have to take the role. But we're not re-litigating the decision.

Output: Voluntary training analysts, clear expectations, scalable onboarding

Enterprise Client Support Playbook

Context: Two large retail clients coming on, business expected to double

Different expectations for enterprise:

• Faster response times?
• Dedicated support contact?
• Proactive check-ins?
• Custom reporting?

Build playbook collaboratively:

• What does "enterprise-level service" mean for FieldStack?
• How is it different from current SMB support model?
• What resources/training do analysts need?

Approach: Collaborative development with team input

Output: Clear enterprise support standards, team prepared for scale

Hiring Plan (If Capacity Gaps Exist)

• Where are the bottlenecks? Volume? Expertise? Coverage?
• What skills do we actually need?
• Hire strategically for specific gaps

Output: Right-sized team for growth trajectory

Regular Sync with Account Management

Purpose: Position support as early warning system

What support sees that Account Management doesn't:

• Ticket volume spikes (churn risk indicator)
• Recurring issues (product/training gaps)
• Customer frustration patterns

The conversation:

"Support isn't just reactive ticket handling - we're your early warning system for account health. When a client's ticket volume spikes 3x, that's a retention risk. Let's build feedback loop."

Output: Support as strategic partner in retention, not just cost center

Product Feedback Loop

Current state: Support handles issues as they come

Future state: Support aggregates patterns and informs product roadmap

Approach:

• Don't forward every bug immediately (engineers need signal, not noise)
• Track patterns over 1-2 weeks
• Quantify impact: How many tickets? What client segments?
• Prioritize ruthlessly: Top 3-5 issues quarterly, not 50
• Provide context: What's the use case? Why does current behavior fail?

Why this works: Engineering becomes ally because you make their lives easier with quality, prioritized input

Output: Product improvements, reduced future support volume

Clear Escalation Framework & Customer Boundaries

Observation from interviews: Current escalation paths appear informal, which can lead to inconsistent customer experiences

Framework for structured escalations:

Tier 1: Standard Support Issues

• Analysts handle independently
• Clear resolution paths
• Measured by response/resolution time

Tier 2: Complex Technical Issues

• Involves engineering/product coordination
• Ticket Coordinator decides (using documented decision tree)
• Analysts coordinate, engineering resolves
• Measured by collaboration effectiveness

Tier 3: Client Relationship Issues

• Account Management owns
• Support provides context and technical details
• Account Management handles relationship dynamics
• Strategic escalation for business-level concerns

Implementation approach:

"We're establishing clearer escalation paths so everyone knows who handles what. This gets customers to the right resource faster and prevents issues from bouncing between teams."

Benefits:

• Customers reach right person for their issue type
• Account Management handles strategic relationship matters
• Analysts focus on technical problem-solving
• Sustainable workload distribution

Frame as service improvement: Better response times, appropriate expertise, clearer communication

Output: Structured escalation framework, sustainable team boundaries, improved customer routing

Cross-Functional Communication Standards

Context: Inconsistent branding/communication across touchpoints may create customer confusion

Questions to explore:

• Does inconsistent email formatting cause support issues?
• Do customers get confused by different communication styles?
• Is this creating extra tickets or escalations?

If yes:

• Collaborate with Marketing on unified customer communication templates
• This is about expectation management, not aesthetics
• Support's lane: How do we work with other orgs to create consistent customer experience?
• Not support's lane: Company-wide brand guidelines (that's Marketing's problem)

Output: Reduced customer confusion, unified communication standards (if needed)