Appendix AData Access & Support Team Liability

What Customer Data Exists?

• Account information (company name, contacts, locations)
• Usage data (what products/features they use, how often)
• Transaction history (purchases, renewals, cancellations)
• Support history (past tickets, issues, resolutions)
• Communication history (emails, calls, notes from other teams)

Who Currently Has Access?

• Sales team: What do they access? How?
• Account Management: What visibility do they have?
• Product/Engineering: Do they query customer data for feature usage?
• Support: Current access level? Read-only? Full access?
• Leadership: Who can see everything?

What Are Support Analysts Looking Up Manually?

• "Who is this customer?"
• "What products do they use?"
• "Have they had this issue before?"
• "Who's their account manager?"
• "When does their contract renew?"

If analysts are asking these questions manually every time, there's an efficiency opportunity. But efficiency without governance = risk.

Are Systems Integrated or Siloed?

• Does ticketing system connect to customer database?
• Can support see account details when ticket comes in?
• Or is it manual lookup in separate system?
• What's the friction in getting customer context?

What Access Does Support Need vs. What Creates Risk?

Essential for support:

• Customer account status (active, trial, canceled)
• Product/feature usage (what they have access to)
• Past support tickets (history of issues)
• Account manager contact (for escalations)
• Basic contact info (who to reach at customer org)

Creates risk without clear governance:

• Payment/billing information (PII, financial data)
• Full contract terms (legal documents)
• Internal company notes not meant for support
• Personal customer data beyond role/contact info
• Write access to production database (accidental changes)

The question: Can we give support what they NEED without exposing them to what they DON'T need?

How Do We Protect Support Team if Broader Governance Is Unclear?

Department-level safeguards support can implement:

1. Read-only access only

• No write access to production customer data
• Queries only, no modifications
• Eliminates accidental deletion/modification risk

2. Staging/reporting database

• Query replica, not production
• Prevents production impact
• Can be more restrictive on what data is exposed

3. Controlled reporting vs. direct SQL

• Pre-built reports for common queries
• Reduces need for direct database access
• Easier to audit what's being accessed

4. Access logging/audit trails

• Track who accessed what customer data, when
• Not about surveillance - about accountability
• Protects analyst if something goes wrong ("I only accessed X, here's the log")

5. Data handling procedures documentation

• What's allowed: Querying for support purposes, viewing in ticketing system
• What's not allowed: Exporting to personal devices, sharing outside support
• Clear expectations protect everyone

6. Training on data sensitivity

• What's PII (personally identifiable information)
• Why customer data security matters
• "If you're unsure, ask before accessing"

What Happens If Something Goes Wrong?

Scenarios to plan for:

Scenario 1: Analyst exports customer data to personal laptop

• Is that allowed? Tracked? Encrypted?
• If laptop is lost/stolen, what's the exposure?
• Who's liable - analyst, manager, company?

Scenario 2: Accidental PII exposure in ticket system

• Customer's payment info accidentally pasted in ticket
• Ticket is visible to other analysts
• What's the incident response?

Scenario 3: Customer requests data deletion (right to be forgotten)

• GDPR/CCPA compliance requirement
• How does support handle this request?
• Who actually executes the deletion?
• How do we verify it's complete?

Scenario 4: Accidental database modification

• Analyst runs UPDATE without WHERE clause (every DBA's nightmare)
• Production data corrupted
• Who's responsible? What's the recovery process?

The point: Clear expectations and safeguards protect the support team from being blamed for systemic issues.

What Works at 30 Customers vs. 30,000

At 30 customers:

• Everyone knows the clients by name
• Manual lookups are fine ("let me check the account")
• Informal knowledge sharing works
• Spreadsheets suffice for tracking
• Personal relationships with customers

At 300 customers:

• Can't rely on memory anymore
• Need searchable customer history
• Formalized handoffs required
• Basic reporting becomes necessary
• Relationships become team-based, not individual-based

At 3,000+ customers:

• Automated data aggregation essential
• Pattern recognition via dashboards required
• Sophisticated tagging/segmentation needed
• Self-service customer portals reduce support volume
• Support becomes data-driven, not relationship-driven

The critical question: Where is FieldStack now (approaching 50+ stores with new enterprise clients), where are they going (business doubling), and how does support data infrastructure need to evolve to support that growth?

How Does Support Fit Into That Evolution?

Phase 1 (Current - Small scale):

• Manual processes acceptable
• Direct customer relationships sustainable
• Basic queries sufficient

Phase 2 (Growth - Medium scale):

• Need standardized processes
• Team-based support model
• Reporting for patterns/trends

Phase 3 (Scale - Large scale):

• Automation required
• Sophisticated data insights
• Proactive vs. reactive support

Support's data needs change at each phase. Plan ahead.

Support as Strategic Function, Not Just Reactive

Current state (likely):

Support reacts to tickets as they come in. Customer data is for "who is this person?"

Future state (opportunity):

Support provides strategic insights based on data patterns.

Examples:

Early Warning System for Account Health

• Ticket volume spike = potential churn risk
• "This client's ticket volume increased 3x this month - Account Management should check in"
• Support becomes proactive partner in retention

Product Feedback Loop

• Common issues by customer segment
• "Enterprise clients all struggle with X feature - Product should prioritize"
• Support informs product roadmap with real usage data

Resource Allocation Insights

• Where is support spending time? Is it proportional to customer value?
• "We spend 40% of time on 10% of customers - why?"
• Data-driven decisions on staffing/prioritization

Customer Success Patterns

• What behaviors correlate with satisfaction?
• "Clients who complete onboarding training have 80% fewer tickets"
• Support insights improve overall customer experience

This is the strategic value of support having proper data access.

But you can't build sophisticated insights on top of broken processes or unclear governance.

Phased Implementation

Phase 1: Assessment (Month 4-5, post-90-day foundation)

• Document current state: What data exists, who has access, what governance framework is in place
• Identify support's essential needs vs. nice-to-haves
• Understand company-wide data governance posture

Phase 2: Department-Level Controls (Month 5-6)

• Implement support-specific safeguards (read-only access, audit logging, data handling procedures)
• Train team on data security expectations
• Document support's data access policies

Phase 3: Strategic Data Use (Month 7+)

• Once foundation and safeguards are solid, explore strategic opportunities
• Build reporting/dashboards for support insights
• Position support as data-driven strategic function

The Conversation to Have (Post-90 Days)

"I've noticed SQL and database work came up during interviews. Before we expand support's use of customer data, I'd like to understand:

• What's the current framework for customer data access and security?
• What governance policies exist (or need to exist)?
• What data does support need to be effective?
• How do we protect the support team from liability?

Not asking support to own company-wide data governance - that's a strategic initiative beyond my scope. But I do need to understand the framework so I can:

• Request appropriate access for support needs
• Implement department-level safeguards
• Train analysts on data handling expectations
• Protect my team if something goes wrong"

If Broader Framework Doesn't Exist

Support can still implement department-level controls:

• Document what data support accesses and why
• Establish audit procedures (who accessed what, when)
• Limit access to minimum necessary (principle of least privilege)
• Train team on "if you're unsure, ask before accessing"
• Build case for company-wide governance framework

Why this matters:

A support analyst who accidentally exposes customer PII because "nobody told me I couldn't" creates liability for them, for me as their manager, and for the company. Clear expectations protect everyone.