Lessons from the frontlines of service delivery

Sabrina Dominguez
January 15, 2020

Team Jazz Casuals here, back with another dispatch from Torontoâs Shelter Support and Housing Administration. In case youâre in need of a refresher, weâre working closely with the divisionâs Policy, Operations and I&T teams to help implement Coordinated Access â a more integrated and consistent approach to assessing, prioritizing and connecting people experiencing homelessness to housing and supports. Implementing this system will involve changing many policies, business processes and operational procedures â and they all intersect with the application powering the divisionâs operations, the Shelter Management Information System (SMIS).
Every shelter in Toronto uses SMIS to manage their beds. The application allows staff to track bed vacancies and admit or refer clients to services where beds may be available. In order to deliver some of the key components of Coordinated Access and improve the experience for clients and staff along the way, the division will need to add new features and functionality to SMIS.
As with any project, there are a lot of things you could do, make or build, so how do you know what to build?
You are not your user
Whether youâre building an app or a clock radio toaster, just because your solution seems right and works for you, doesnât mean it will make sense or work for other people (known as the False-Consensus Effect). To combat this bias and reduce the risk that users wonât like, need or be able to use what you create, itâs good to start by trying to understand your users and their needs better.
This means going to where your users are and observing them engage with your product or service in context. It means listening to the kind of language they use, noticing their behaviour, trying to understand their routines, habits and workflows. Do they use any other tools? Have they created any shortcuts? When do they get frustrated?
Since SMIS is an internal tool, City and shelter staff are our most direct users. They have to abide by certain rules and standards and follow certain protocols. The tools available to them shape their experiences and workflows.
The experience weâre focusing on is the first set of interactions a client has when they enter a shelter. Internally, this process is called âintakeâ and it can set the stage for a clientâs stay and any subsequent work they may do with shelter staff. One of the pillars of Coordinated Access is a more standardized approach to identifying client needs in the form of something called a Common Assessment, which is meant to facilitate more equitable resource allocation and match people to the supports that best meet their needs.
To better understand how staff get to know clients when they first enter a shelter and how the tools they use help or hinder the process, we had to get out of the office and hit the frontlines.
The goals of our research
- Get to know our users (shelter staff who use SMIS)
- Gain a better understanding of staff and client pain points, challenges and unmet needs
- Understand and document the intake experience, journey and processes
What we did
Criss-crossing across Toronto, we initially visited five different City and non-profit operated shelters and engaged with 23 staff. The primary methods we used were unstructured interviews and observation.
We spoke with frontline staff, shelter supervisors, client support workers and housing counsellors. Some were new to the work; others were 20+ year veterans in the field. They came from different backgrounds, had different levels of education and philosophies, but they all cared deeply about their work.
They showed us how they fill their paperwork â what goes where and when, whatâs important and what they never bother to fill in. They clicked us through the screens and programs they use most frequently â SMIS, Word docs, spreadsheets, forms and other case management tools. We witnessed staff scramble to locate a translator for a refugee who arrived with mountains of documents. We observed as they rifled through printed logs (âListed alphabetically now, finally!â), communicated with colleagues (âAnything to pass down from shift change?â) and continue working, unfazed, when something was thrown at a window (âWe donât say have a good shift, we say âstay safeââ).
Itâs one thing to hear or read about âpolicyâ and a whole other thing to witness it action. Policy, and things like technical specifications, often describe what should happen, but do not say how. That part has to be designed.

Key findings and how theyâve informed our work
As is often the case with research, users can help you discover things you werenât necessarily looking for and point to areas of greater impact or more urgent priority.
Two inextricably linked takeaways have informed our work moving forward.
âWeâre grasping in the darkâ â Shelter staff
Valuable information is either not available or difficult to store and access
Shelters workers can see a clientâs history in their particular program, but not much else. Having a better picture of a clientâs history across the whole system would go a long way in preventing staff from repeatedly collecting information a client may have already shared â a major frustration for everyone.
Information such as the length of time someone has been homeless and whether they are considered âchronically homelessâ is not currently available but could be a valuable signal that helps supervisors and staff be more proactive in their outreach and engagement with clients. We know that if someone has been in shelter for six months, there is a much higher chance that theyâll become a longer-term occupant. After certain lengths of time, clients may also become eligible for more tailored programs or services. Without visual cues, itâs difficult to track and remember how long dozens of people have been staying in your shelter.
How might we surface more actionable data to inform client prioritization and engagement?
For our minimal viable product, we want to give staff the ability to see and sort their clientele by the length of time theyâve been at the shelter (number of nights theyâve occupied a bed) so that they can see â at a glance â who has been there the longest and take appropriate action.
Data permissions and sharing policy are too strict and inhibit continuity of care
Many of the pain points we discovered are actually the result of a feature, not a flaw. When SMIS was originally built, service providers were less comfortable sharing client information, so data-sharing across the shelter network was kept to a minimum. It is now apparent that the inability to see and share data between shelters and services leads to a frustrating experience and much more work.
For instance, there are a number of things people need in order to secure housing: a source of income, taxes and ID; social housing applications help too. Collectively, these are referred to as âhousing essentialsâ. Itâs difficult to search for and secure housing without them. The sooner staff know whether a client has these documents, the sooner they can assist the client and help them look for housing opportunities.

One of the biggest staff and client frustrations is that documents and information uploaded or entered at one shelter are not visible to staff at other shelters or programs.
âYou end up repeating a lot rather than picking up where you left offâ â Shelter staff
We heard that clients regularly complain about being asked for the same information (âI already gave that at the last placeâ) and staff wish that key pieces of information like âhousing essentialsâ were visible across the system.
How might we share key information across shelters and programs to improve continuity of service and improve the client experience?
What this looks like is limited by some backend constraints, so weâre starting with the most simple technical solution. Weâre advocating that a clientâs assessment information â a form which contains their housing essentials and other information that can inform in-shelter support â be viewable at a new location if and when clients give consent.
Changing the divisionâs data sharing policy may not happen in our remaining months, but by raising frontline staff voices and surfacing these pain points weâre building momentum.
You can learn from the frontlines too!
You donât have to be an anthropologist to do user research. Spending time with frontline staff observing and paying close attention to how they do their work can reveal plenty of ways a product, service, process or program can be improved.
The time we spent with frontline staff quickly clarified how we might improve their tools and help them help clients more effectively.
Whether youâre in the public, private or non-profit sector, frontline staff, like customer service or tech support representatives, are a direct line to your customers, clients or the people you serve. Look for where they get stuck and frustrated but also how they solve problems in unique or creative ways â it may inspire ideas for how to improve the experience for everyone.
Donât forget, staff are your users too!
The Code for Canada fellowship embeds technology professionals into government, where they work alongside public servants to build great digital services. To learn more about becoming a fellow, or hosting a team of fellows in your department, visit codefor.ca/fellowship.