In order to facilitate easier knowledge transfer and general awareness of client needs, a new process has been created. We call this process the ‘Client Briefing’ procedure.
Client Briefings are created and maintained by Client Owners. They act as a quick way to get up to speed on any clients we currently have and are maintained to make sure that information on them does not get out of date. There is a new checklist item for this which has been added to the template checklist board.
If you’re working with a client for the first time, you’re encouraged to go into the CRM Client Board and read up on them. Of course, there are no briefings to speak of at the moment, since this process is still new. I will be refining and creating tickets for an epic next week for inclusion in the upcoming sprint to get these initial Client Briefings written by existing Client Owners.
Note the content of the templates here-- I’m anticipating this will eventually replace our ‘maintained instances’ list. I hope that this will clear a great deal of the confusion that surrounds working with new clients, and also gets more developers familiar with the tools and processes used by BizDev, as we like having our dev team members as involved in the sales process as practical.
Thank you to those who reviewed this procedure and I look forward to collaborating with you all on the initial briefing work!
@Fox I’ve noticed that I’m unable to locate clients in the CRM by searching for their site URLs (see e.g. url 1, url 2) or any other details only on the client briefing updates. Is monday.com not search indexing our updates? Can we make it do that?
I think this needs to be fixed before we can remove the maintained_instances page.
@Fox I’ve noticed that I’m unable to locate clients in the CRM by searching for their site URLs (see e.g. url 1, url 2) or any other details only on the client briefing updates. Is monday.com not search indexing our updates? Can we make it do that?
Unfortunately the view for that is not ‘in-line’ as we might like. You can do it, however. To search for the right client, click the magnifying glass on the toolbar on the left-hand (the one with your profile picture). This brings up ‘search everything’ Select the ‘updates’ options from the options under the search field and start typing the URL there.
NOTE: You’ll need to start searching the URL by protocol, so don’t forget the https. Seems the indexing requires you to search by the start of a term.
However the UX for this is awful and slow.
The searching on the board itself appears to be done entirely within the frontend. The issue is that the updates aren’t fetched automatically and available for the search to look through. What we could do is use a ‘long text’ field and have it updated with the contents of all updates. Then search would always have what it needs to work. It will require some API shenanigans, but if needed, I’ll create a task for adding this.
I didn’t have to use the protocol in my search terms, just the domain worked fine?
If the “Item Card” fields are flexible/customizable, I think it would be better to use them to store the formatted data in the Client Briefing template, and then use pinned Updates to store paragraph text, like background info and current project details.
I didn’t have to use the protocol in my search terms, just the domain worked fine?
Cool! It didn’t work for me XD
If the “Item Card” fields are flexible/customizable, I think it would be better to use them to store the formatted data in the Client Briefing template, and then use pinned Updates to store paragraph text, like background info and current project details.
I’m not sure what you mean by 'Item Card" fields. We can add several fields where formatted data can live, but the number of needed fields would vary per client if we wanted to store, say, all the relevant URLs, or else we’d have to use the ‘long text’ field, which would work but doesn’t allow any formatting, just ‘plain’ text, which would be harder to bring up and read, especially with the way it displays the field.
If we could add multiple URL fields for things like LMS, Studio, Insights, Staging LMS, secure repo, AWS account, etc., does that make this info easier to find? Or does it just clutter everything?
Yuck, plain text isn’t good, and I’m not a fan of auto-duplicating updates into plain text either
But I am ok with the “Update search” workaround, it just needs to be documented and disseminated.
This would be very cluttered since some clients have multiple of each of these, and there’s no limit to how many they may have of any.
@gabor is on the job :) And yeah, it’s a hacky work-around. But I think it will be mostly invisible in practice, since in the board mode we can make it the right-most column so it will be off-screen most of the time.
Misunderstood-- I see now you mean you prefer the workaround with the magnifying glass on the left side. We can do that, but I think it’s quite a ‘gotcha’ and I don’t think it will be very intrusive in practice to add in the indexing and the wider search behaves inconsistently and slowly for me. Are you sure?
I’m not fussed If the text duplication is unobtrusive and doesn’t create its own confusions, then it’ll be worth doing that to make these records more discoverable for everyone.
There’s a subtlety to this procedure which I’d like some clarity on:
To keep things up to date, Client Owners will write an update to the CRM entry for each meeting or signficant interaction they have with the client. Once a sprint, they will consolidate the updates to the most important points and recreate the initial briefing with the most up to date context.
I read this to mean, “each sprint, update your initial briefing to add any new information gained from interacting with the client”, but @tikr has been adding a new Update to summarize the details from each sprint meeting.
Which should we be doing? Or should we be doing both, so we can see when things changed?
When I came up with this procedure, I wasn’t certain how many interactions per sprint one might have with the client, and how often one might come across information best kept in the initial client briefing. So I wrote the maintenance procedure to be a two-stage process:
Write down the results of your updates.
Every so often, consolidate these updates into the initial client briefings, pruning out information which didn’t stay relevant to people coming onboard for the first time.
Initially, I was going to have the task to consolidate happen every few sprints. But our checklist only has vision for one sprint at a time, so I just made the consolidation happen every sprint. If one only meets with the client once a sprint, this step may be redundant. If there is a sprint with heavy client interaction, it may be important to catalog each of these and then reconcile by the end.
Perhaps a better approach would be to place a conditional on the reconciliation like ‘If it’s the first sprint of the month, reconcile.’ What do you think?
Do you mean, “write a new Update in the CRM for each interaction”? That’s what I’m not clear on. I write down notes during meetings, and make sure the actions are communicated to whomever needs to do them on tasks and whatever, but I haven’t been putting an update in the CRM each time.
So to use the tired old “hit by a bus” adage, if I was hit by a bus after a client meeting before I’ve had the chance to ping everyone, those actions would likely get lost.
I’m ok with the “every so often” reconciliation being monthly. But I do want it emphasised that this is the most important role of this CRM entry – to provide a concise “where are things now” update for a given client.
But you’re right, since our process is sprint-by-sprint, I’ve been doing this reconciliation every sprint, and leave off adding individual new Updates.
Writing updates after meetings is what was meant, yes, or if they sent an email with any significant information. The primary purpose is to get anyone who is unfamiliar with a client up to speed as quickly as possible. The combination of the long-running and maintained client briefing alongside the most recent updates is what allows that. This is also helpful for ‘bus factor’ situations, as you point out.
@jill@Fox For additional context, I’ve been posting updates on monday.com for information from meetings that I felt was “universally” relevant (i.e., that wasn’t just related to one or more specific tickets). If a client didn’t provide this type of information during a meeting, I didn’t post a separate update for that meeting on monday.com. And for ticket-specific information I’ve been doing what @jill mentioned above, i.e., communicating it to others by posting comments on JIRA tickets as necessary. This has been working well for me in the sense that it made updating the main CRM entry for a client at the end of the sprint pretty straightforward.
@Fox Does that align with what you had in mind? I feel like it does, but let me know if you think that individual CRM updates should include more info.
@Fox, do we have any follow-ups for this? It would be great to have a single source of truth instead of maintaining both of them, as they’ll eventually get out of sync for some entries. Relevant comment - I can rewrite this client’s update to Markdown (I’m not aware of another way around this with Monday’s WYSIWYG editor) and then copy it to Monday with each update, but it’s tedious. Or, we can just put the Monday link in there for reference, as an intermediary solution.
cc: @anon46505572
If the text duplication is unobtrusive and doesn’t create its own confusions, then it’ll be worth doing that to make these records more discoverable for everyone.
