DEVLOG #8

ㅤ
It’s been a long time since I wrote my last journal and that is because I just didn’t feel like writing a journal. It just seemed like too much work. I was also busy studying so I could not code and journal as frequently but I have made significant changes to my Lead handling ideas and I would like to share them.
ㅤ

LEAD GENERATION CHANGES

Basically, I have decided on a flow where a user can send multiple queries at the same time to generate leads from and choose the number of leads that they want to generate for each query. This would make work faster if a user wants to target a diverse set of businesses.
ㅤ
while generating leads, the user will see 2 options. In the first one, the user will be asked to enter their query. In the second one, the user will be asked to add an upper limit to their search.
ㅤ
There will also be a “+” button at the bottom of each “query box” of “query batch” so that a user can add another query box and mix and match how many leads they want and what queries they want. both questions are required for a query and hence there will be a continue button only when both a re filled. If the user adds a new box then the continue button will again disappear until both of the new questions are filled and so on and so forth.
ㅤ

BATCHES

Every lead generation is now given its own batch. A batch can be managed easily by going to a new “Manage Leads” tab where the user can do all sorts of stuff like view generation history, view all batches, push generated batches to the team, remove batches, break up batches, set deadline on batches, etc.
ㅤ

LEAD PUBLISHING

Earlier, the flow was such that the boss generates the leads and the leads are there for everyone in the team to view immediately. We do not want that. Instead, now the flow is that when the leads are generated, they are only visible to the boss so that they could tune the batch by adding deadlines and stuff. Then, when the boss is ready, they can publish the full batch to the common workspace where all the employees can see the leads and pick them up.
ㅤ

WORKING ON LEADS

once the leads are published, the employees in the team can pick up leads and start working on them. This is the flow that I have decided upon.
ㅤ
Claim Leads -> Work on Claimed leads -> Log outcome of call -> Complete lead
ㅤ
It is as simple as that. As per the endpoints we have /leads/{lead_id}/claim to claim a lead, /leads/{lead_id}/log to make a log for a lead and /leads/{lead_id}/complete to complete a lead. There is also an endpoint /leads/{lead_id}/return which is used to return a claimed lead back to the common pool.
ㅤ

ㅤ
code wise there have been a lot of changes like new lead_batches and call_record tables and a lot more stuff so I won’t go in depth about all that because then the journal would be too long and I honestly do not want to spend much time journaling and I would rather spend more time coding.
ㅤ
While writing this journal, I also thought of a bug for my scraper logic:
ㅤ
Imagine if a user wants 10 leads for dentists in delhi, the user scrapes and the scraper only looks at the first 10 businesses even though there are 124 businesses. Next, the user wants leads for dentists in Delhi again the next day so the user scrapes again. Now, since the scraper does not know if this business already exists in the database, it will just give the same 10 businesses as before and all get marked as duplicate event though we have other 114 businesses. But, they will never be scraped because the search is linear and the scraper has no context of, this lead exists, leave it.
ㅤ
So, I think I will be spending my trying to fix this bug somehow as this is pretty serious.
ㅤ
commit: 45f5e2d4107b23bd4a7609aaf17fd0bafb566bcf