
Housing Associations are currently navigating complex demands. Balancing elevated resident expectations with the intense regulatory scrutiny imposed by the Housing Ombudsman. Additionally, they handle the daily reality of supporting front-line teams.
My expertise, built on 20-plus years of lived experience on the front lines of social housing, helps associations move from a blank piece of paper to a brand-new or updated CRM system designed to meet these challenges head-on.
I follow a 5-Phase Blueprint that transitions from strategy to go-live. From Phase 1 (Strategy) we move into Phase 2.
Phase 2, officially titled Process Definition and Specification, is the critical point in the blueprint. It is where your high-level strategy (Phase 1) becomes the technical instructions needed for system development.
This phase can be broken down into three main steps:
Moving you from the concept of how work flows to the precise details needed to build the system. In this phase, you are the Translator, ensuring that the specifications are detailed, organised, and unambiguous.
This is where our customer service needs (“We need to solve this complaint faster”) are translated into the technical instructions (“Create an automated workflow triggered by ‘Complaint Stage 1’ with these three data fields”) that our IT colleagues need to build.
For our IT teams, this phase is their shield against scope creep and vague requests. For us in Customer Service, this phase is our guarantee that what gets built will actually solve our problems.
A Note to My Customer Service Peers: Why IT is Your Co-Pilot, Not Just Your BuilderBefore we jump into the three steps, I want to add a special note for my Customer Service peers. The only way Phase 2 succeeds is with deep collaboration with our IT teams.
The successful execution of Phase 2 and the subsequent development hinges on this collaboration. They are our primary experts on the system’s architecture and how it connects to everything else. We act as the “Translator” of business needs, but IT’s involvement from day one is what ensures our “translations” are technically feasible, scalable, and secure. This is how we build a solid foundation.
Here’s where we must work with them:
Project Foundation: This collaboration starts before Phase 2. We need their guidance on the toolkit itself. They provide the crucial context on the available tools, which influences our choice of system (e.g., the cost and skill difference between a premium Dynamics app vs. a more tailored Model-Driven Power App).
Architectural Integrity (The Spec): During the specification, we must work with IT to make key architectural decisions. This includes:
Security Architecture: Our spec must define the security rules. IT will architect the solution so we can protect sensitive data. For example, in a staff conduct complaint, we can design it so only managers can see the sensitive details, while others only see the high-level case. This extends to essentials like Multi-Factor Authentication (MFA) and ensuring our data stays safe.
In short, our IT team is the architectural backbone of this entire project. Based on my experience, involving them early and often in Phase 2 is the key to getting this right.
This is where we map our processes, but not just as boxes and arrows on a page. We must move from a theoretical “how it should work” to “how it actually works,” including all the pain points. I use complaint handling to explain more about
Why it Matters to Customer Service (Us):
This is our chance to fix what’s broken. By walking through the journey with residents and staff, we identify the real bottlenecks. Where do staff get stuck? Where do customers have to wait?
The Complaint Handling Code Example: This is our non-negotiable. We don’t need to reinvent the wheel; the Housing Ombudsman’s code is our framework. Our process map must build in every regulatory milestone. We can’t just hope for compliance; we must design the system to enforce it, like the 5-day acknowledgement. This is our “hard lifting” already done.
Why it Matters to IT (Our Partners):
This step gives our IT team the “business rules.” A clear map shows them exactly where a process starts (a customer call, a webform), what decisions are made (“Is it a formal complaint?”), and what the required outcomes are (an acknowledgement letter, a resolution). Without this, they are forced to guess, and that’s a risk we can’t afford.
Once the map is agreed upon, we translate it into system-level detail. This means defining two things: the data we need to capture (Fields) and the work we want to automate (Flows).
This is, in my opinion, the most critical part of the entire specification.
Why it Matters to Customer Service (Us):
This step is our liberation from manual tracking. Think about the stress of managing complaint deadlines on a spreadsheet. “Fields & Flows” is how we fix that.
- Fields: We get to define the picklists that will finally give us real insight. We can stop guessing and start knowing.
- The “Free Text” Trap: We must be ruthless here. Every free text box is a black hole for reporting. By defining “Complaint Subtype” as a picklist (e.g., “Damp & Mould,” “Staff Attitude,” “Repair Delay”), we can instantly see our biggest problems.
- Flows (Automation): This is our staff’s new best friend. When a complaint is logged, the system automatically calculates and sets the acknowledgement and response due dates. This isn’t just a “nice to have”; it removes a huge administrative burden and reduces the risk of human error.
Why it Matters to IT (Our Partners):
This step gives our IT team the “data model and logic.”
- Fields: They can build a clean, efficient database. When we fight for picklists over free text, we are giving them reportable, structured data. They want to give us good reports, and this is how we help them do it.
- Flows (Automation): This is the core workflow logic. Our requirement (“The system must set a 5-day SLA”) becomes a specific, buildable rule in the system. This clarity is essential for them to build a solution that is robust and manageable long-term.
This is the final step where everything comes together in the “spec” document. But before that, we have to make some big decisions and, crucially, visualise the result.
Why it Matters to Customer Service (Us):
We’ve all seen our teams suffer the “Swivel-Chair Nightmare”—bouncing between the CRM, the Housing Management System (HMS), spreadsheets, and sticky notes. This is our chance to end it.
- The “Single View” Myth: We all want a “single view of the customer,” but this doesn’t mean we have to copy all the data from every system into the new CRM.
- Wireframes/proof of concepts: This is non-negotiable. We must see simple mock-ups of the screens before they are built. This is where we catch things like “Wait, the ‘Vulnerability’ flag isn’t visible on the first screen” or “The team needs to see the tenancy number here.”
- Integration: We need to be pragmatic. Do we really need to migrate 20 years of tenancy history? Or do we just need to see the current tenancy status?
Why it Matters to IT (Our Partners):
This step gives our IT team the “technical architecture.” Our decisions here have massive implications for budget, timelines, and technical skill.
- Build vs. Buy: As we discussed with them earlier, the spec finalises this. Is the premium Dynamics 365 Customer Service App required, or can 90% of our needs be met with a more tailored Model-Driven Power App?
- Integration: Our “pragmatic” decision on data is their technical instruction. When we say, “Just show us the HMS data,” they hear, “Okay, we can build a simple view (like an Iframe or URL link) instead of a complex, high-risk data migration.”
- Example: By using a common key like the tenancy number (held in both systems), the spec can define a simple link. Our staff click a button, and the CRM passes the tenancy number to the HMS, which opens to the exact customer record. The staff member gets the info, the customer journey is seamless, and our IT team just saved months of complex integration work. That’s a win-win.
Completing Phase 2 doesn’t just give us a thick “spec” document. It gives us a shared agreement. Colleagues know what’s coming and have seen the system in action and the IT Team know what needs to be in place, and when, to make it happen.
It’s the contract between Customer Service and IT, built on a common language. It proves we’ve done the hard work of translation. It de-risks the build (Phase 3) and ensures that the system we get is the system we actually need—one that serves our customers, supports our staff, and satisfies the regulator.
Watch this essential workshop where housing professionals unpack the precise, proven, and actionable methodology to achieve Ombudsman readiness in just three steps.
We need a quick proof of concept to help back our business case: Struggling to secure funding for your #Dynamics or #Powerapps implementation? Need to show what they can do? then this is for you
Our business case has been approved but we need help to get going: We know that it can be overwhelming. Where do you start, how do you bring your business case to life? Our #D365ForHousing package can help you get going
We’ve started our Dynamics/Power Apps project but struggling to find the time to gather some serious momentum: This is a tough one, the will is there and everyone is up for it but you just struggle to find the time to get things moving while you do the ‘day job’. Our project support service can help lighten the load
We just need a bit of training or access to some handy templates: Then this Business Analysis 101: A Simple and Effective Course for Non-BAs course may be of use or perhaps visit our store to access some handy templates

Hi, I’m Chris Roberts Director at E&F Solutions.
I’m a Dynamics consultant helping UK housing associations escape rigid legacy CRM systems and overpriced suppliers.
With over 20 years in housing operations, I specialise in translating complex user needs into precise plans. This ensures we deliver a system your teams genuinely love, freeing up funds to be reinvested into building new homes & communities.
Original Post https://deliveringcrm.net/2025/11/18/mastering-phase-2-process-definition-for-crm-success/






