早上坐下来准备一份报价:先是电话响了,接着客户到了门口,然后传来一条故障消息。到了傍晚,报价还只做了一半。
在小企业里,一天常常被当下进来的事填满,而重要却好像可以等的活会被落在后面。本文用一连串问题,谈怎样分清急事和要紧事,并为要紧事挤出时间。
⚡ 示例场景:一家空调维修店整天接到故障电话,保养计划和没发出的报价要排队等上几周。发现一单因为报价太晚而被别家接走之后,店里决定把早上的第一个小时留给报价,并先简单判断打进来的电话。这个习惯可能有助于减少要紧事被落在后面的情况。
急事和要紧事有什么不同
急事是别人等着马上处理的活;要紧事影响生意的明天,却好像可以等。 一件事急,未必说明它要紧;要紧事安静,反而容易被排到后面。
下表汇总了活的类型、例子和可以采取的做法。
| 类型 | 例子 | 可以怎么做 |
|---|---|---|
| 又急又要紧 | 客户等着今天修好的故障 | 马上处理 |
| 要紧但不急 | 准备报价、写工作说明 | 在日程里留固定时间 |
| 急但不要紧 | 可以等的咨询 | 简短回复或往后排 |
| 既不急也不要紧 | 白天冒出来的小杂事 | 攒着做或有空时做 |
| 别人能做的活 | 例行的订单核对 | 说明后交出去 |
急事怎样填满一天
白天进来的新请求往往打断手上的活,把注意力拉到最后来的那件。 电话、消息和上门的客户接连不断时,一天可能结束了也没回到原本要做的活。
一天开始前先定下第一件活,可能让它不至于淹没在请求里。前一天定下明天第一件活的做法,我们在下班前为明天做的准备一文中谈过;这里说的是白天有请求进来时的判断。
被推后的要紧事什么时候变急
放着等的要紧事,会随着时间变少而挪进急事的名单。 没有备份的电脑或推后的报价,可能在某个意外的日子成为当天唯一的话题。
像备份这样安静却要紧的活怎么安排,我们在电脑坏掉前的检查一文中讲过。给推后的活定一个新日期怎样帮助它不被忘记,我们在会议后的任务为什么被遗忘一文中谈过。
为什么每件事都显得急
有些活显得急,不是因为真的急,而是因为发现得晚。交期临近的活在最后一天才发现缺东西,那天它就可能挤到别的活前面。
交付前先核对活、提前说清日期,可能减少留到最后一刻的事;这份准备的步骤,我们在向客户交付工作前的准备一文中谈过。开始一个新请求之前,先问一句是今天就要做,还是可以排队,也能让区分更容易。
怎样为要紧事留出时间
要紧事的时间,往往来自在日程里特意为它空出的位置。
要守住这段时间,可以看三种做法。
1. 留出一天的第一个小时
一天的第一个小时,电话和来访可能还不多。把这个小时留给一件要紧事,可以减少它在白天被推后的次数。
2. 把打断集中起来
把等回复的消息和电话放在固定时段集中查看,可以减少每来一条提醒就放下手上活的情况。真正紧急的情况,可以留一条能找到人的路。
3. 把要紧事拆成小块
把长的活拆成能塞进短时间的小块,忙碌的一天也能往前推。每块结束时记下做到哪里,回到这件活时会更容易。
怎样减少急事
急事里有一部分,根源是本可以早点发现的小缺口。 把反复出现的急事记在一张清单上,就能看出哪些本可以提前处理。
比如,为问同样问题的电话准备好答复、为快用完的材料早点下单、按时做一次检查,都可能让这些活变急的次数变少。这些准备本身,也属于要紧但不急的活。
哪些活可以交给别人
急事里有一部分,懂这件活的其他人也能做。看看哪些活可以交出去,能为要紧事留下更多时间。
| 活 | 谁可以做 | 怎样交出去 |
|---|---|---|
| 常见的咨询 | 接电话的员工 | 用准备好的答复 |
| 例行订单核对 | 熟悉订单的员工 | 用简短的说明 |
| 安排预约 | 前台的员工 | 用共享日程 |
| 简单故障的分流 | 有经验的员工 | 当面示范 |
| 材料查看 | 熟悉库房的员工 | 用一份简单清单 |
把活交出去之前,可能需要说明它怎么做。什么时候适合写成说明、什么时候适合当面示范,我们在写成说明还是手把手教一文中谈过。
小结
急事挤掉要紧事时,影响生意明天的活可能被一再推后。分清急事和要紧事、减少因为发现得晚才显得急的活、在日程里给要紧事留固定位置、把打断集中起来、把一部分活交出去,可能有助于找到这个平衡。与其拒绝请求,不如把它排进合适的顺序,多数情况下就够了。
常见问题
怎样分清急事和要紧事?
急事是别人等着马上处理的活;要紧事影响生意的明天。问一句今天不做会有什么变化,区分就容易一些。
要紧的活为什么会被落下?
要紧的活通常很安静,没人马上催。白天进来的请求更显眼,先去处理它们会更容易。
怎样减少白天的打断?
把等回复的消息和电话放在固定时段集中查看,会有帮助。真正紧急的情况可以留一条能找到人的路。
可以把哪段时间留给要紧事?
打断还不多的一天第一个小时可能合适。把这段时间留在日程里,并把长的活拆开,会有帮助。
是不是该拒绝请求?
与其拒绝,不如把请求排进合适的顺序,多数情况下就够了。告诉客户什么时候处理,等待也更容易理解。
