OutreachOps

• 

  Logo

Inspiration

Outreach work needs a fast answer to one question. Where is help needed most right now. Many existing tools rely on pin level maps or individual tracking. That can create stigma, abuse risk, and fear of being targeted. We wanted a different approach that still supports real operations. OutreachOps started from one hard constraint. We will not track individuals. We will only use grid level signals that are safe to summarize and easy to act on.

What it does

OutreachOps is a grid only outreach operations dashboard designed for homelessness response. It helps teams see demand patterns, compare them to available capacity, and decide what to do next. People or field staff submit a request by selecting a grid cell and a category. No precise location is required and no pin is shown. Providers or partner organizations can update capacity and availability for services. The dashboard ranks cells by a need resource gap score. This means we do not prioritize the loudest area. We prioritize the place where demand is high and capacity is low. Outreach teams can log actions and outcomes, and the app updates two operational metrics. Backlog represents unresolved demand. Average response time represents how quickly a request receives a recorded outreach action.

How we built it

We built OutreachOps as a mobile first web app with three pages. Dashboard, Request, and Safety. Dashboard is the main operations view. It shows a real map with a visible grid overlay and a priority list. Each cell shows a small numeric signal so changes are easy to verify during a short demo. Request is a focused input flow. The user chooses a category, taps a grid cell, and submits. Safety is a dedicated checklist that makes the rules explicit and easy to audit.

We implemented three simple mechanisms to connect safety and operations. First, APG. We use a privacy threshold over a short time window. If a cell does not have enough signals, we mark it as data insufficient instead of showing detailed hints. Second, CWS. Signals are weighted by source and time. Repeated or suspicious bursts are down weighted so spam does not dominate the map. Third, NRGI. We compute priority as demand divided by capacity plus a small epsilon. This keeps the ranking stable and aligns decisions with resource gaps.

We store only grid identifiers and non identifying fields. We do not store precise coordinates, addresses, or personal data. We also add basic abuse protection such as rate limiting and simple surge detection. If the online database is unavailable, the app can fall back to demo mode so the core flow still works.

Challenges we ran into

The biggest challenge was balancing usefulness and privacy. A grid that is too fine can become risky, and a grid that is too coarse can lose operational value. We also had to prevent noisy public inputs from overwhelming the system. Instead of building complex moderation, we focused on lightweight weighting and visible safeguards. Another challenge was making the demo convincing. We needed the end to end loop to be obvious on screen. Submit a request, see the grid and priority list update, change capacity and see re ranking, then save a log and see KPI values change.

Accomplishments that we're proud of

We are proud that OutreachOps works as an operations tool rather than a static map. The app makes decisions explainable because ranking is tied to a clear demand and capacity gap. We are also proud of the safety by design approach. The interface avoids pins and individual tracking, and the data model stores only what is needed. Finally, we built the demo around measurable changes. Backlog and response time are visible, and they update from real actions rather than manual storytelling.

What we learned

We learned that social impact software is not only about features. It is also about what not to collect. Constraints can improve design when they are treated as first class requirements. We also learned that operational metrics matter. A dashboard is more credible when it shows outcomes and not only heat. Finally, a good demo is a product feature. If the end to end loop is clear, judges and users can trust that the idea is implementable.

What's next for OutreachOps

Next, we want to test the workflow with more realistic partner scenarios and refine how capacity is represented across different service types. We also want to improve signal validation while keeping the system lightweight and privacy preserving. Another step is better reporting for organizations, such as weekly summaries and coverage checks, without exposing individuals. We will keep the same core rule. Grid only signals, no pins, and no individual tracking.

Built With

• css
• github
• githubactions
• html
• javascript
• openstreetmap
• pages