Knock

• 

  Rep office locator screen

• 

  QR code at a doctors office for the rep to scan

• 

  Rep form to fill in from QR code

• 

  Acceptance if the rep and product are a fit

• 

  Deferral if they are not a fit

• 

  Office is not accepting reps screen

• 

  Medical office rep management page

• 

  Door sign configuration screen to vet reps

• 

  Rep meeting time preference screen for doctors

• 

  Rep messages to medical office page

• 

  Demand signals page

Inspiration

In the context of pharma sales, a lot of medical offices limit rep visits, but many of them would still make time for a rep if the topic was relevant to their patients. The problem is that there isn't really a way for an office to say that. Reps tend to plan their day around prescribing and engagement data, drive out to an office, and only find out at the front desk whether anyone there wants to hear about what they're bringing. This costs the front desk time, the doctor ends up in conversations that may not fit their practice, and the brand never learns what the office was actually interested in. Most existing tools look at prescribing data to tell reps who is worth visiting, so I wanted to build something that uses what the office says about itself to tell reps who is willing.

What it does

Knock gives each medical office a Door Sign that says whether it's taking rep visits, which therapeutic areas it wants to hear about, when reps can come by, and how many visits it takes in a week. The doctor can change the sign by editing the settings manually or by speaking to an AI that autofills each field. Reps can check a fit list that ranks every office by how well it matches their products, or scan a QR code at the front desk, and in a few seconds they get either a visit time or whatever the office offers instead, such as a virtual meeting, dropping off samples, or the next open slot. Safety communications are always accepted no matter how the sign is set. On the office side, the front desk has a live Lobby Board where requests show up as they come in, and they can change any answer with one tap, which also emails the rep. Further, every request feeds into Demand Signals, which is built for brand teams. It shows things such as offices that want a therapeutic area but haven't hosted a visit from that brand, where reps went to offices that weren't interested in their area, and offices that recently opened up, and each number shows where it came from. An office's private preferences and how full its week is are never shown to reps or brands, and a single brand's view only counts that brand's own requests.

How I built it

I built Knock solo with Next.js, TypeScript, Tailwind, and shadcn/ui, hosted on Vercel. Supabase handles the database and realtime updates, which is what lets a QR scan on a rep's phone show up on the office's Lobby Board right away. The decision engine is one plain TypeScript function with no AI in it, and it runs the same fixed list of checks in order every time, so the office can always see why a request got the answer it did and any change to the sign applies to the very next request. Grok is only used on the office side to make setting up or adjusting an office's sign faster. In Talk mode, Grok reads each setup question out loud, transcribes the doctor's answer, and turns it into that one setting, and it can only pick from fixed options like known topics and times so an answer that isn't about rep visits doesn't change anything. I also used the NPI Registry to pre-fill office details and Resend to email reps when the desk changes their answer. The demo uses fictional offices in real Atlanta neighborhoods and fictional brands in real therapeutic areas, and the 30 days of history were generated by running the actual decision engine against each office's sign.

Challenges I ran into

The biggest challenge was enabling doctors to set up their sign by voice with the fields filled in by AI, since it took a lot of debugging browser permissions and making sure the AI only picked from a set of predetermined choices. Another challenge was deciding what each side gets to see, since reps and brands need enough information to act on while offices need their private preferences to stay private, and every answer had to be useful to the rep without revealing the reason behind it.

Accomplishments that I'm proud of

I'm proud of how simple the app is and purpose-built for its specific function. I put a lot of effort into pruning extraneous features or design choices that would've made the app more difficult to use, or introduced extra complexity that didn't add any value.

What I learned

One key takeaway is how much the framing of the product shapes how people react to it. When Knock is described as a way for offices to manage rep visits, it can come across as something that works against reps, but the value is really in the matching, where doctors get relevant visits and more time for patients, reps spend their day at offices that want to see them, and brands get demand data they couldn't see before.

What's next for Knock

I would like to explore monetization strategies and get feedback from practices, reps, and drug companies to get a better idea of how this might fit into their workflow, or where it doesn't.

Built With

• javascript
• next.js
• shadcn
• supabase
• tailwind
• typescript
• vercel