Project 02 · Analyze

Los Angeles
Service Operations

An analyst-style investigation of public MyLA311 service-request data: document the source, inspect data quality, transform raw records into operational measures, identify demand and service patterns, and translate the findings into management questions.

Data provenance

City of Los Angeles · MyLA311

Publisher: City of Los Angeles Information Technology Agency. Dataset: MyLA311 Service Request Data 2024. The City describes it as service requests submitted through 3-1-1, call centers, email, mobile apps, websites and other sources. The published dataset has 34 columns and includes creation/update dates, owner, request type, status, source, assignment, service/closure dates and geographic fields.

Open official source ↗

This page can query the City's public Socrata API for a live analytical snapshot. If the API is unavailable, methodology remains visible and no synthetic results are substituted.

01 · SOURCEPublic MyLA311 records

02 · PROFILENulls, dates, status, coordinates

03 · TRANSFORMResolution time + time buckets

04 · ANALYZEDemand, channel, owner, geography

05 · RECOMMENDOperational questions/actions

Live snapshot

What does the service system look like?

—Published requests

—Closed share

—Request types

—Owners / agencies

Top request types

Load the live snapshot to populate.

Request channels

Load the live snapshot to populate.

Geographic QA

Do the records support spatial analysis?

Why map the raw sample?

This is deliberately a data-quality view, not a polished heatmap. I inspect whether coordinates are present and plausible before using geography for executive conclusions.

Load the public-data snapshot to inspect a recent coordinate sample.

For a production model, I would then normalize geography into council district / neighborhood / service area and keep the original latitude/longitude for drill-through.

Transformation logic

What I did to the source data

-- Example analytical SQL after ingestion SELECT request_type, owner, status, request_source, created_date, closed_date, EXTRACT(EPOCH FROM (closed_date - created_date))/3600 AS resolution_hours, CASE WHEN closed_date IS NULL THEN 'Open' WHEN closed_date - created_date <= INTERVAL '24 hours' THEN '<= 24 hours' WHEN closed_date - created_date <= INTERVAL '72 hours' THEN '24-72 hours' ELSE '> 72 hours' END AS resolution_band FROM myla311 WHERE created_date IS NOT NULL;

Source field	Derived / QA treatment
CreatedDate	Parse timestamp; derive month, weekday and hour.
ClosedDate	Parse timestamp; calculate resolution duration only when valid.
Status	Standardize labels; separate open/pending/closed/canceled states.
RequestType	Trim/normalize categories; inspect long-tail values.
Owner / AssignTo	Profile responsibility and missing assignment.
Latitude / Longitude	Type-check, reject null/implausible coordinates before mapping.
RequestSource	Normalize intake channels for channel-mix analysis.

Analyst questions

The dashboard is not the conclusion.

Demand

Which request types and geographies generate disproportionate volume? Is demand seasonal or concentrated by day/channel?

Service delivery

Which categories remain open longest? Are differences explained by request type, ownership, assignment, or intake channel?

Data quality

Where are closure dates, assignments or coordinates incomplete enough to distort a performance metric?

Management action

Which bottlenecks deserve staffing, routing, self-service, process redesign or deeper root-cause analysis?

Methodology disclosure

What is source data vs. my work?

Element	Origin
Service-request records and published fields	City of Los Angeles MyLA311 open data.
Field definitions	City of Los Angeles dataset metadata.
Resolution-hours / bands	My derived analytical measures.
Time buckets and normalized categories	My transformation layer.
QA rules for nulls/dates/coordinates	My data-quality methodology.
Operational questions and recommendations	My analysis; not City of Los Angeles conclusions.

Los AngelesService Operations